Instant Redis

OPcache è un'estensione PHP che memorizza nella cache il codice PHP compilato, cosi' PHP non deve ricompilarlo ad ogni richiesta. Dovrebbe assolutamente abilitarlo — può migliorare le prestazioni di PrestaShop del 30-50% senza controindicazioni per la produzione. La maggior parte dei provider di hosting lo ha abilitato per impostazione predefinita. L'impostazione importante è opcache.validate_timestamps: impostata su 1 in sviluppo, ma molti server di produzione la impostano su 0 per le massime prestazioni (il che significa che deve resettare manualmente OPcache dopo aver distribuito modifiche al codice).

See our full guide on PHP optimization

Generalmente si — il CCC combina più file CSS in uno e più file JS in uno, riducendo le richieste HTTP e migliorando i tempi di caricamento. Tuttavia, il CCC può causare problemi se il CSS/JS di un modulo ha requisiti specifici sull'ordine di caricamento o usa attributi defer/async. Se abilita il CCC e qualcosa si rompe (solitamente un problema visivo o un errore JS), verifichi quali asset del modulo stanno causando il problema e configuri quel modulo per mantenere i suoi asset separati.

Learn more about CSS/JS optimization

Ottimizzazioni gratuite per le prestazioni: (1) Abiliti OPcache in PHP (impatto enorme, costo zero). (2) Abiliti la cache Smarty e il CCC (Combina, Comprimi, Cache) di PrestaShop. (3) Disabiliti i moduli non utilizzati — ogni modulo attivo aggiunge overhead anche se non mostra nulla di visibile. (4) Ottimizzi le immagini prima del caricamento (usi tinypng.com o simili). (5) Abiliti la cache delle query MySQL. (6) Si assicuri di non essere in modalita' debug. Solo questi accorgimenti possono raddoppiare la velocità' delle pagine.

See our real-world PageSpeed 99 case study

Disabilitare completamente la cache rendera' il Suo negozio notevolmente più lento. Invece, svuoti la cache correttamente: Parametri Avanzati → Prestazioni → Svuota cache. Se i problemi persistono dopo lo svuotamento: elimini manualmente il contenuto di /var/cache/prod/ e /var/cache/dev/. Per la cache Smarty: verifichi se "Forza compilazione" è impostata su "Si" (dovrebbe essere "No" in produzione). Se un modulo specifico non funziona con la cache, lo segnali allo sviluppatore del modulo — è un bug che va corretto.

Understand PrestaShop caching in depth

Utilizzi gli Strumenti per sviluppatori del Suo browser (F12 → scheda Network) per identificare cosa è lento. Cause comuni: (1) Un modulo che carica script esterni pesanti (font, analytics, widget chat). (2) Un modulo che esegue query lente al database — verifichi la barra del profiler Symfony in modalita' debug. (3) Troppi moduli registrati sullo stesso hook (es. displayHeader). (4) OPcache disabilitato sul server. (5) Risorse dell'hosting al massimo. Disabiliti i moduli uno alla volta per identificare il colpevole.

See how we achieved PageSpeed 99 with 80+ modules

Entrambi funzionano bene. PrestaShop supporta ufficialmente MySQL 5.7+ e MariaDB 10.x+. MariaDB è spesso leggermente più veloce per carichi di lavoro pesanti in lettura (come tendono ad essere i negozi e-commerce). La maggior parte dei provider di hosting offre l'uno o l'altro. Se ha scelta, MariaDB 10.11 LTS è un'opzione solida. La differenza di prestazioni è minima per la maggior parte dei negozi — si concentri sull'indicizzazione corretta e l'ottimizzazione delle query piuttosto che sulla scelta del motore database.

Read about database optimization for PrestaShop

PrestaShop stesso funziona bene con 256MB di limite di memoria PHP per la maggior parte dei negozi. Tuttavia, se ha molti moduli installati, cataloghi di prodotti grandi o esegue operazioni di importazione/esportazione, potrebbe aver bisogno di 512MB o più. Il server stesso dovrebbe avere almeno 2GB di RAM per un piccolo negozio, 4GB+ per negozi medi con la cache abilitata. Questi sono i minimi — più ce n'e' meglio e'.

Read our performance tuning recommendations

Vada in Parametri Avanzati → Prestazioni e clicchi "Svuota la cache". Questo pulisce i template compilati di Smarty e la cache di Symfony. Per una pulizia più approfondita: elimini anche il contenuto di /var/cache/ manualmente (sia la cartella prod che dev). Se usa OPcache, potrebbe anche dover riavviare PHP-FPM o Apache per pulire la cache del codice operativo. Il semplice svuotamento della cache di PrestaShop non pulisce OPcache.

Learn about caching strategies for PrestaShop

Come funzionano i modelli di e-mail PrestaShop

PrestaShop invia e-mail transazionali in ogni momento chiave del percorso del cliente: creazione dell'account, conferma dell'ordine, notifica di spedizione, reimpostazione della password e molto altro. Queste e-mail vengono generate da file modello archiviati sul vostro server e sono completamente personalizzabili. Comprendere il funzionamento del sistema di modelli è il primo passo per creare e-mail di conferma ordine professionali e coerenti con il brand, che rafforzino l'identità del vostro negozio.

Ogni e-mail PrestaShop è composta da due file modello: una versione HTML per i client di posta che supportano la formattazione avanzata e una versione in testo semplice (TXT) per i client di posta che non la supportano. Entrambi i file devono essere presenti affinché un'e-mail venga inviata correttamente. La versione HTML è quella che la stragrande maggioranza dei vostri clienti vedrà. La versione TXT serve come fallback ed è utilizzata anche dagli strumenti di accessibilità e da alcuni filtri di posta aziendale.

I modelli di e-mail si trovano nella struttura di directory mails/. La posizione esatta dipende dall'utilizzo di e-mail del core, e-mail sovrascritte dal tema o e-mail specifiche di un modulo. Comprendere questa gerarchia è essenziale, poiché PrestaShop controlla più posizioni per ogni modello e utilizza il primo che trova.

La struttura delle directory dei modelli e-mail

PrestaShop organizza i modelli di e-mail in una gerarchia di directory specifica. Quando deve inviare un'e-mail, il sistema cerca in queste posizioni in ordine di priorità:

Override a livello di tema (Priorità massima)

I modelli in /themes/vostro-tema/mails/it/ (dove it è il codice ISO della lingua) hanno la priorità su tutte le altre posizioni. Se desiderate personalizzare un modello di e-mail senza modificare i file del core, è qui che i vostri modelli personalizzati devono essere collocati. Questo approccio sopravvive agli aggiornamenti di PrestaShop poiché i file del tema non vengono sovrascritti durante gli aggiornamenti del core.

Modelli del core (Predefiniti)

I modelli predefiniti si trovano in /mails/it/ nella directory principale di PrestaShop. Questi sono i modelli forniti con PrestaShop e vengono utilizzati quando non esiste alcun override del tema. Modificare direttamente questi file funziona, ma non è consigliato poiché le vostre modifiche andranno perse con l'aggiornamento di PrestaShop.

Modelli specifici per modulo

I moduli che inviano le proprie e-mail archiviano i modelli in /modules/nome-modulo/mails/it/. Ad esempio, le e-mail di notifica ordine inviate dai moduli di pagamento del core sono archiviate nelle rispettive directory dei moduli. Potete sovrascriverle inserendo copie modificate nella directory mails/ del vostro tema con lo stesso nome file.

Sottodirectory linguistiche

Ogni directory mails/ contiene sottodirectory per ogni lingua installata, utilizzando il codice ISO della lingua: en per l'inglese, fr per il francese, de per il tedesco e così via. Quando PrestaShop invia un'e-mail, utilizza il modello dalla directory corrispondente alla preferenza linguistica del cliente. Se un modello non esiste nella lingua del cliente, PrestaShop utilizza la lingua predefinita.

Anatomia di un modello di conferma ordine

L'e-mail di conferma ordine è l'e-mail transazionale più importante che il vostro negozio invia. Si tratta del file denominato order_conf.html (e del suo accompagnatore order_conf.txt) nella vostra directory mails. Esaminiamone la struttura nel dettaglio.

Struttura del modello HTML

I modelli di e-mail PrestaShop sono documenti HTML autonomi. Non utilizzano file CSS esterni poiché la maggior parte dei client di posta rimuove i fogli di stile esterni. Tutto lo styling deve essere CSS inline. Un tipico modello di conferma ordine include queste sezioni:

Il documento inizia con un doctype HTML standard e una sezione head. Il body contiene un layout basato su tabelle (poiché i client di posta hanno scarso supporto per i metodi di layout CSS moderni come flexbox e grid). All'interno di questo layout trovate una sezione di intestazione con il logo del vostro negozio, l'area di contenuto principale con i dettagli dell'ordine, una tabella prodotti che elenca ogni articolo ordinato, un riepilogo dei prezzi con subtotali e totali, informazioni sulla spedizione, dettagli del metodo di pagamento e un piè di pagina con le informazioni di contatto del negozio e le note legali.

Il sistema di variabili

PrestaShop utilizza un semplice sistema di sostituzione delle variabili nei modelli di e-mail. Le variabili sono racchiuse tra parentesi graffe: {nome_variabile}. Quando l'e-mail viene generata, PrestaShop sostituisce ogni variabile con il suo valore effettivo. Il modello di conferma ordine utilizza queste variabili chiave:

{firstname} e {lastname} contengono il nome del cliente. {order_name} è il numero di riferimento dell'ordine (come ABCDEF123). {shop_name} è il nome del vostro negozio come configurato nel back office. {shop_url} è l'URL del vostro negozio. {shop_logo} è il percorso dell'immagine del logo del vostro negozio. {date} è la data dell'ordine. {payment} è il metodo di pagamento utilizzato. {total_paid} è l'importo totale pagato. {delivery_company} e {delivery_address} contengono le informazioni sul corriere e l'indirizzo di consegna.

Per l'elenco dei prodotti, PrestaShop utilizza una sintassi a blocchi speciale. La sezione degli articoli è racchiusa in un ciclo che si ripete per ogni prodotto nell'ordine: {items} contiene l'HTML preformattato per l'intera tabella dell'elenco prodotti, inclusi nomi dei prodotti, quantità, prezzi e tutti i dettagli di personalizzazione.

Riferimento delle variabili disponibili

Per vedere tutte le variabili disponibili per un modello di e-mail specifico, consultate il codice PHP che invia l'e-mail. Per la conferma ordine, controllate la classe PaymentModule (in /classes/PaymentModule.php). Il metodo validateOrder() costruisce l'array delle variabili del modello. Ogni chiave nell'array corrisponde a un nome di variabile che potete utilizzare nel modello.

Le variabili comunemente disponibili nelle e-mail di conferma ordine includono: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} e {total_products}.

Personalizzare il modello di conferma ordine

Passaggio 1: Creare un override del tema

Non modificate mai direttamente i file dei modelli del core. Copiate invece il modello nella directory mails del vostro tema:

Copiate /mails/it/order_conf.html in /themes/vostro-tema/mails/it/order_conf.html. Fate lo stesso per order_conf.txt. Se la directory mails/it/ non esiste nel vostro tema, createla.

Se il vostro negozio supporta più lingue, copiate i modelli per ogni directory linguistica. La vostra conferma ordine in francese va in /themes/vostro-tema/mails/fr/order_conf.html e così via.

Passaggio 2: Modificare il layout HTML

Aprite il modello HTML in un editor di testo (non un editor visuale che potrebbe aggiungere codice indesiderato). L'HTML per le e-mail differisce dall'HTML per il web in diversi aspetti importanti:

Utilizzate le tabelle per il layout, non i div. I client di posta, in particolare Outlook, hanno un supporto CSS molto limitato. Un layout a tre colonne deve utilizzare un <table> con tre elementi <td>, non colonne CSS o flexbox.

Utilizzate stili inline su ogni elemento. Invece di <p class="heading"> con un foglio di stile separato, usate <p style="font-size:18px; font-weight:bold; color:#333333;">. Ogni elemento stilizzato necessita del proprio attributo di stile inline.

Impostate larghezze esplicite su tabelle e celle. I client di posta non rispettano sempre le larghezze percentuali. Utilizzate una larghezza fissa per la vostra tabella di contenuto principale (600 pixel è lo standard) con colonne interne percentuali.

Utilizzate font web-safe. Non tutti i client di posta supportano font personalizzati. Attenetevi ad Arial, Helvetica, Georgia, Times New Roman, Verdana o Trebuchet MS. Potete provare a caricare un font personalizzato come fallback, ma specificate sempre un font web-safe come fallback finale.

Passaggio 3: Aggiungere il vostro branding

Sostituite l'intestazione PrestaShop predefinita con il branding del vostro negozio. Questo tipicamente comporta l'aggiornamento del logo (la variabile {shop_logo} utilizza automaticamente il logo del vostro negozio, ma potreste volere una versione specifica per le e-mail), la modifica del colore di sfondo dell'intestazione per abbinarsi al vostro brand, l'aggiunta della palette colori del vostro brand ai titoli e ai link, e l'inclusione del tagline del vostro negozio o di un breve messaggio promozionale.

Mantenete la struttura complessiva semplice. Design di e-mail eccessivamente complessi si rompono in diversi client di posta. Un layout pulito a colonna singola con i colori e il logo del vostro brand è più efficace e affidabile di un elaborato design multicolonna.

Passaggio 4: Personalizzare la tabella prodotti

La tabella prodotti predefinita nella conferma ordine PrestaShop è funzionale ma essenziale. Potete migliorarla aggiungendo immagini dei prodotti (utilizzate URL assoluti a immagini ospitate sul vostro server, non percorsi relativi), aggiungendo link alle pagine prodotto affinché i clienti possano facilmente riordinare o lasciare recensioni, aggiungendo campi personalizzati come date di consegna stimate o messaggi personalizzati, e regolando lo stile della tabella per abbinarsi al vostro brand.

Quando aggiungete immagini dei prodotti, mantenetele piccole (da 50 a 80 pixel di larghezza) e includete sempre un attributo alt. Alcuni client di posta bloccano le immagini per impostazione predefinita, e il testo alternativo garantisce che i clienti possano comunque identificare i loro prodotti.

Aggiungere campi personalizzati alle e-mail degli ordini

Le variabili predefinite di PrestaShop coprono le informazioni standard dell'ordine, ma potreste voler includere dati aggiuntivi come punti fedeltà guadagnati, data di consegna stimata, un messaggio di ringraziamento personalizzato o raccomandazioni di prodotti in cross-selling.

Aggiungere variabili tramite un modulo

Il modo più pulito per aggiungere variabili personalizzate è attraverso un modulo che si aggancia al processo di invio delle e-mail. Create un modulo che registra l'hook actionEmailSendBefore (disponibile da PrestaShop 1.7.6) o l'hook actionGetExtraMailTemplateVars. Nel vostro gestore dell'hook, aggiungete le vostre variabili personalizzate all'array delle variabili del modello:

La vostra funzione hook riceve l'array delle variabili del modello per riferimento. Potete aggiungere nuove variabili a questo array e diventano disponibili nel modello utilizzando la sintassi standard {nome_variabile}. Ad esempio, dopo aver aggiunto loyalty_points all'array nel vostro hook, potete utilizzare {loyalty_points} nel vostro modello HTML di conferma ordine.

Utilizzare i dati esistenti del database

Potete inserire qualsiasi dato dal vostro database PrestaShop nelle variabili delle e-mail. Esempi comuni includono il conteggio totale degli ordini del cliente (per mostrare "Grazie per il tuo 5° ordine!"), il saldo dei punti fedeltà del cliente, campi prodotto personalizzati memorizzati nelle caratteristiche o attributi dei prodotti, e informazioni sul magazzino o fornitore per i prodotti ordinati.

Configurazione delle e-mail multilingue

Se il vostro negozio serve clienti in più lingue, ogni modello di e-mail necessita di una versione per ogni lingua. PrestaShop gestisce automaticamente la selezione della lingua in base alla preferenza linguistica del cliente, ma dovete fornire i modelli.

Creare modelli specifici per lingua

Per ogni lingua supportata dal vostro negozio, create una directory nella cartella mails del vostro tema: /themes/vostro-tema/mails/en/, /themes/vostro-tema/mails/fr/, /themes/vostro-tema/mails/de/ e così via. Copiate e traducete ogni file modello nella directory appropriata.

Non utilizzate la traduzione automatica per le e-mail transazionali. Queste e-mail rappresentano la comunicazione del vostro negozio con i clienti, e traduzioni scadenti danneggiano la fiducia. Fate scrivere o revisionare ogni versione linguistica da un madrelingua.

Supporto per le lingue da destra a sinistra

Se supportate lingue come l'arabo o l'ebraico, i vostri modelli di e-mail necessitano del supporto per il layout RTL (da destra a sinistra). Aggiungete dir="rtl" all'elemento tabella principale e regolate l'allineamento del testo e i padding nei vostri stili inline. Create modelli separati per le lingue RTL piuttosto che cercare di far funzionare un singolo modello per entrambe le direzioni.

Formattazione di date e valute

PrestaShop formatta automaticamente i valori di date e valute secondo le impostazioni di lingua e valuta del cliente. I valori {date}, {total_paid} e altri valori formattati riflettono già le impostazioni locali corrette. Tuttavia, se aggiungete variabili personalizzate con valori di date o valute, assicuratevi di formattarle correttamente per la lingua di destinazione.

Configurazione SMTP per una consegna affidabile

Il miglior modello di e-mail del mondo è inutile se le vostre e-mail non raggiungono la casella di posta in arrivo. La configurazione predefinita delle e-mail di PrestaShop utilizza la funzione mail() integrata di PHP, che è inaffidabile per le e-mail transazionali. La maggior parte di queste e-mail finisce nella cartella spam o viene completamente rifiutata dai provider di posta moderni.

Perché l'SMTP è importante

L'SMTP (Simple Mail Transfer Protocol) con autenticazione appropriata è essenziale per la deliverability delle e-mail. Quando inviate e-mail tramite la funzione mail() di PHP, l'e-mail proviene dall'indirizzo IP del vostro server web senza alcuna autenticazione. I provider di posta come Gmail, Outlook e Yahoo vedono questo come un segnale d'allarme e spesso classificano queste e-mail come spam.

Con l'SMTP, le vostre e-mail vengono inviate attraverso un server di posta autenticato con record SPF, DKIM e DMARC appropriati. Questo dimostra ai server di posta riceventi che l'e-mail è legittima e autorizzata dal vostro dominio.

Configurare l'SMTP in PrestaShop

Andate su Parametri avanzati > E-mail nel vostro back office PrestaShop. Cambiate il metodo da "Usa la funzione mail() di PHP" a "Imposta i miei parametri SMTP". Inserite i dettagli del vostro server SMTP: l'indirizzo del server, la porta (tipicamente 587 per TLS o 465 per SSL), il tipo di crittografia, il nome utente e la password.

I provider SMTP comuni per PrestaShop includono Gmail SMTP (smtp.gmail.com, porta 587, TLS, richiede una password per le app se la 2FA è abilitata), Amazon SES (conveniente per volumi elevati), SendGrid (generoso livello gratuito), Mailgun (developer-friendly con buona registrazione) e il server SMTP del vostro hosting provider (verificate con il vostro host per le impostazioni).

Testare la configurazione SMTP

Dopo aver configurato l'SMTP, utilizzate il pulsante "Invia un'e-mail di test" in fondo alla pagina di configurazione delle e-mail. Inserite il vostro indirizzo e-mail e verificate che l'e-mail di test arrivi nella vostra casella di posta in arrivo (non nello spam). Se l'e-mail di test fallisce, verificate le vostre credenziali SMTP, assicuratevi che il vostro server possa raggiungere il server SMTP sulla porta configurata (alcuni hosting provider bloccano le porte in uscita 25 e 587) e controllate se il vostro provider SMTP richiede impostazioni di sicurezza specifiche.

Record SPF, DKIM e DMARC

Per la massima deliverability, configurate questi record DNS per il vostro dominio. SPF (Sender Policy Framework) specifica quali server sono autorizzati a inviare e-mail per conto del vostro dominio. DKIM (DomainKeys Identified Mail) aggiunge una firma digitale alle vostre e-mail che prova che sono state inviate dal vostro dominio. DMARC (Domain-based Message Authentication, Reporting, and Conformance) dice ai server riceventi cosa fare con le e-mail che non superano i controlli SPF o DKIM.

Il vostro provider SMTP vi fornirà i record DNS specifici da aggiungere. Ad esempio, se utilizzate SendGrid, forniscono i record SPF e DKIM durante il processo di autenticazione del dominio. Aggiungeteli come record TXT nelle impostazioni DNS del vostro dominio.

Testare i modelli di e-mail

Invio di e-mail di test

PrestaShop non ha un modo integrato per visualizzare in anteprima modelli di e-mail specifici. Per testare il vostro modello di conferma ordine, dovete effettuare un vero ordine di test. Create un account cliente di test, aggiungete prodotti al carrello e completate il checkout con un metodo di pagamento di test. Se avete un modulo di pagamento sandbox configurato, utilizzatelo. Altrimenti, i metodi di pagamento tramite bonifico bancario o assegno vi permettono di completare un ordine senza elaborazione del pagamento effettiva.

Test su diversi client di posta

Il rendering delle e-mail varia drasticamente tra i client di posta. Quello che appare perfetto in Gmail potrebbe essere rotto in Outlook. Come minimo, testate i vostri modelli in Gmail (web), Outlook (desktop e web), Apple Mail, Yahoo Mail e almeno un'app di posta mobile. Servizi come Litmus o Email on Acid automatizzano questi test renderizzando la vostra e-mail in decine di client di posta contemporaneamente, ma sono servizi a pagamento.

Problemi di rendering comuni

Se la vostra e-mail appare rotta in Outlook, è quasi certamente un problema di CSS. Outlook utilizza il motore di rendering di Microsoft Word per le e-mail HTML, che ha un supporto CSS estremamente limitato. Non supporta immagini di sfondo sulle celle delle tabelle (utilizzate colori di sfondo al loro posto), padding sugli elementi blocco (utilizzate il padding delle celle delle tabelle), max-width (utilizzate larghezze fisse), margin per il centraggio (utilizzate align="center" sulle tabelle) e float CSS.

Per la responsività mobile, avvolgete la vostra tabella di contenuto in un contenitore con max-width:600px e aggiungete una media query nel blocco di stile dell'head (che alcuni client di posta supportano) che imposta le larghezze delle tabelle al 100% su schermi piccoli. Questo non è un design responsive perfetto, ma previene lo scrolling orizzontale sulla maggior parte dei dispositivi mobili.

Problemi comuni e risoluzione

Immagini mancanti nelle e-mail

Questo è il problema più comune dei modelli di e-mail. Le immagini nelle e-mail devono utilizzare URL assoluti (che iniziano con https://), non percorsi relativi. Se il vostro modello fa riferimento a /img/logo.png, cambiatelo in https://www.vostrodominio.com/img/logo.png. La variabile {shop_logo} genera automaticamente un URL assoluto, ma tutte le immagini che aggiungete manualmente devono utilizzare URL completi.

Verificate inoltre che le vostre immagini siano accessibili dall'esterno della vostra rete. Se il vostro negozio è dietro un firewall o un'autenticazione HTTP, i client di posta non possono caricare le immagini. Testate aprendo l'URL dell'immagine in una finestra del browser privata/in incognito.

Layout rotto dopo la modifica

L'HTML delle e-mail è fragile. Un singolo tag non chiuso o una cella di tabella mancante può rompere l'intero layout. Validate sempre il vostro HTML dopo la modifica. Contate i vostri tag di apertura e chiusura table, tr e td. Ogni <table> necessita di un </table>, ogni <tr> necessita di un </tr> e ogni <td> necessita di un </td>. Verificate che ogni riga in una tabella abbia lo stesso numero di celle (o utilizzi colspan per compensare la differenza).

Variabili non sostituite

Se vedete il testo letterale {nome_variabile} nelle vostre e-mail inviate invece dei valori effettivi, controllate il nome della variabile per errori di battitura. I nomi delle variabili sono case-sensitive. Verificate inoltre che la variabile esista per il tipo specifico di e-mail che state personalizzando. Non tutte le variabili sono disponibili in tutti i modelli di e-mail. Le variabili specifiche dell'ordine come {order_name} sono disponibili solo nelle e-mail relative agli ordini.

Le e-mail non vengono inviate affatto

Se le e-mail non vengono inviate, controllate il back office PrestaShop sotto Parametri avanzati > E-mail. Qui potete vedere un registro delle e-mail inviate. Se il registro mostra errori, controllate la vostra configurazione SMTP. Se nessuna e-mail appare nel registro, l'e-mail potrebbe non essere attivata affatto. Verificate che le transizioni di stato dell'ordine siano configurate per inviare e-mail al cliente (Ordini > Stato > modifica stato > spuntate "Invia un'e-mail al cliente").

Controllate anche il registro errori PHP del vostro server per errori relativi alle e-mail. Problemi comuni includono la funzione mail() di PHP disabilitata dal provider di hosting, errori di autenticazione SMTP dovuti a password modificate e problemi di connettività di rete tra il vostro server e il server SMTP.

Le e-mail finiscono nello spam

Anche con una configurazione SMTP corretta, le e-mail possono comunque finire nello spam. Le ragioni più comuni sono record SPF/DKIM/DMARC mancanti o errati, contenuto dell'e-mail che attiva i filtri antispam (uso eccessivo di lettere maiuscole, parole che attivano lo spam come "gratis" o "agisci ora", troppe immagini con poco testo), invio da un indirizzo IP con cattiva reputazione (comune con l'hosting condiviso) e l'indirizzo e-mail "da" il cui dominio non corrisponde al dominio del server SMTP.

Correggete prima i record DNS, poi esaminate il contenuto delle vostre e-mail. Utilizzate uno strumento come mail-tester.com per analizzare le vostre e-mail alla ricerca di elementi che attivano lo spam. Inviate un'e-mail di test all'indirizzo che forniscono e riceverete un rapporto dettagliato che mostra cosa potrebbe causare la classificazione come spam.

Override e-mail specifici del tema

Alcuni temi PrestaShop includono i propri modelli di e-mail che corrispondono al design del tema. Se il vostro tema ha modelli in /themes/vostro-tema/mails/, questi sovrascrivono automaticamente i modelli del core.

Verificare i modelli e-mail del tema

Cercate nella directory del vostro tema attivo una cartella mails. Se esiste, il tema fornisce modelli di e-mail personalizzati. Questi modelli solitamente corrispondono alla palette colori e al design dell'intestazione/piè di pagina del tema, conferendo alle vostre e-mail coerenza visiva con la vostra vetrina.

Personalizzare i modelli e-mail del tema

Se il vostro tema fornisce modelli di e-mail, modificate quelli invece di copiare dalla directory mails/ del core. I modelli del tema possono utilizzare una struttura HTML diversa o includere CSS aggiuntivo specifico per il sistema di design del tema. Partire dalla versione del tema garantisce coerenza visiva.

Mantenere i modelli sincronizzati con gli aggiornamenti del tema

Quando aggiornate il vostro tema, controllate se l'aggiornamento include modifiche ai modelli di e-mail. In tal caso, le vostre personalizzazioni potrebbero essere sovrascritte. Prima dell'aggiornamento, fate il backup dei vostri modelli personalizzati. Dopo l'aggiornamento, confrontate i nuovi modelli con i vostri backup e riapplicate le personalizzazioni alle versioni aggiornate. È tedioso ma necessario per mantenere sia le vostre personalizzazioni sia eventuali miglioramenti o correzioni apportati dallo sviluppatore del tema.

Best practice per le e-mail di conferma ordine

Un'e-mail di conferma ordine ben realizzata fa molto di più che confermare la transazione. Costruisce fiducia, riduce le richieste di supporto e crea opportunità di coinvolgimento.

Includete un numero di riferimento dell'ordine chiaro e ben visibile in alto. I clienti hanno bisogno di questo numero quando contattano il supporto o tracciano il loro ordine. Elencate ogni prodotto con il suo nome, la quantità, il prezzo e tutte le opzioni o personalizzazioni. Includete il dettaglio completo di subtotale, costi di spedizione, tasse, sconti e totale. Mostrate l'indirizzo di consegna affinché i clienti possano verificarlo e contattarvi immediatamente se è sbagliato. Indicate il metodo di pagamento utilizzato e tutti i dettagli della transazione pertinenti. Fornite un link alla pagina di tracciamento dell'ordine o allo storico ordini del cliente nel suo account. Aggiungete le informazioni di contatto del servizio clienti affinché i clienti sappiano come raggiungervi in caso di problemi.

Mantenete il design pulito e mobile-friendly. Più della metà di tutte le e-mail viene letta su dispositivi mobili. Utilizzate un layout a colonna singola, testo grande e leggibile (minimo 14px per il testo del corpo) e pulsanti con target touch adeguati (minimo 44px di altezza). La vostra e-mail di conferma ordine è un riflesso della professionalità del vostro negozio. Investite il tempo necessario per farla bene.

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.