Integrazione Viber Chat

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

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.

Lazy Loading nel 2026: cosa gestiscono nativamente i browser e cosa richiede un modulo

Il lazy loading e una tecnica di ottimizzazione delle prestazioni che differisce il caricamento delle risorse fuori schermo fino a quando l'utente non scorre vicino ad esse. Nel 2026, il supporto nativo dei browser per il lazy loading e maturato significativamente, ma ci sono ancora scenari in cui i proprietari di negozi PrestaShop hanno bisogno di moduli aggiuntivi o implementazioni personalizzate. Questa guida spiega esattamente cosa i browser gestiscono da soli, quali lacune rimangono e come implementare la migliore strategia di lazy loading per il tuo negozio PrestaShop.

Cosa copre il lazy loading nativo nel 2026

L'attributo HTML loading="lazy" e ora supportato da oltre il 95% dei browser a livello mondiale. Questo include Chrome (dalla v77), Firefox (dalla v75), Safari (dalla v15.4), Edge (dalla v79) e tutti i browser basati su Chromium.

Come funziona il lazy loading nativo

<img src="immagine-prodotto.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nome prodotto">

Cosa i browser gestiscono nativamente

Cosa i browser NON gestiscono

Implementare il lazy loading nativo in PrestaShop

Per i temi PrestaShop 8.x e 9.x

{* Prima - senza lazy loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Dopo - con lazy loading nativo *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Regola critica: mai lazy loadare le immagini above-the-fold

L'errore piu comune del lazy loading e applicarlo alle immagini visibili senza scorrimento. Questo in realta peggiora le prestazioni perche il browser ritarda il caricamento del contenuto che l'utente vede immediatamente.

Immagini che NON devono essere lazy loadate:

• Il logo del tuo negozio
• Immagini hero/banner in cima alla pagina
• Le prime 1-2 immagini prodotto nelle pagine categoria

<img src="hero-banner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Banner promozione estiva">

Quando serve un modulo: immagini di sfondo CSS

I temi PrestaShop usano frequentemente immagini di sfondo CSS per slider, banner e intestazioni di categoria. L'attributo loading="lazy" non funziona per gli sfondi CSS.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Quando serve un modulo: effetti placeholder

• Effetto blur-up (LQIP) - Carica prima una versione piccola e sfocata
• Schermate scheletro - Blocchi placeholder grigi corrispondenti alle dimensioni
• Placeholder colore dominante - Usa il colore dominante dell'immagine come sfondo

Impatto su prestazioni e Core Web Vitals

• LCP - Il lazy loading delle immagini above-the-fold PEGGIORA il LCP
• CLS - Le immagini senza attributi width/height causano spostamenti del layout
• INP - Meno risorse caricate simultaneamente migliorano l'interattivita

<!-- MALE - causa spostamento layout -->
<img src="prodotto.jpg" loading="lazy" alt="Prodotto">

<!-- BENE - riserva spazio -->
<img src="prodotto.jpg" loading="lazy" 
     width="400" height="400" alt="Prodotto">

Raccomandazioni specifiche PrestaShop

Pagine lista prodotti

Lazy loadare tutte le immagini prodotto tranne la prima riga. Applicare fetchpriority="high" alla prima riga.

Pagine dettaglio prodotto

L'immagine principale deve essere caricata eager con fetchpriority="high". Le miniature della galleria possono essere lazy loadate.

Riepilogo: Modulo vs. Nativo

Rate Limiting e protezione dai bot per PrestaShop senza WAF

I bot rappresentano oltre il 40% del traffico web nel 2026. Questa guida mostra come implementare una protezione efficace usando solo configurazione server, regole .htaccess e moduli leggeri.

Metodo 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Metodo 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Metodo 3 - fail2ban contro il brute force

fail2ban monitora i log del server e blocca automaticamente gli IP malevoli.

Metodo 4 - Rate Limiting a livello PHP

Per l'hosting condiviso: rate limiter basato su file in PHP.

Metodo 5 - robots.txt e controllo del crawling

User-agent: SemrushBot
Crawl-delay: 10

Metodo 6 - CAPTCHA sui form critici

Aggiungere reCAPTCHA su login, registrazione, contatto e newsletter.

Metodo 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode e Rate Limiting sono disponibili gratuitamente.

Riepilogo dei livelli di protezione

Redirect .htaccess PrestaShop: scrivere regole senza rompere il negozio

Il file .htaccess e uno dei file piu potenti e pericolosi nella tua installazione PrestaShop. Un singolo carattere fuori posto puo mettere offline l'intero negozio. Ma padroneggiare i redirect .htaccess e essenziale per la SEO.

Come PrestaShop usa .htaccess

PrestaShop genera e gestisce automaticamente il file .htaccess. Quando attivi gli URL semplificati nelle impostazioni SEO e URL, PrestaShop scrive regole di riscrittura tra due commenti marcatori.

Regola critica - Non aggiungere mai i tuoi redirect personalizzati all'interno di questo blocco. PrestaShop li sovrascrivera alla prossima rigenerazione. Posiziona le tue regole PRIMA del blocco PrestaShop.

Tipi di redirect

301 - Redirect permanente

Usa quando una pagina si e spostata permanentemente. I motori di ricerca trasferiscono il valore SEO al nuovo URL.

302 - Redirect temporaneo

Usa quando una pagina e temporaneamente non disponibile.

410 - Gone

Usa quando una pagina e stata rimossa permanentemente senza sostituto.

Sintassi di base dei redirect

Redirect 301 /vecchia-pagina.html https://tuonegozio.com/nuova-pagina.html
Redirect 301 /vecchio-prodotto.html https://tuonegozio.com/it/nuovo-prodotto.html

Redirect basati su pattern con RewriteRule

RewriteEngine On
RewriteRule ^vecchia-cartella/(.*)$ https://tuonegozio.com/nuova-cartella/$1 [R=301,L]

Scenari comuni di redirect PrestaShop

Scenario 1 - Migrazione da un'altra piattaforma

RewriteRule ^product/vecchio-slug/?$ https://tuonegozio.com/it/nuovo-url.html [R=301,L]

Scenario 2 - Forzare HTTPS e WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Regole che possono rompere PrestaShop

Loop di redirect infiniti

L'errore piu pericoloso. Usa sempre condizioni per prevenire i loop.

# PERICOLOSO
RewriteRule ^(.*)$ https://tuonegozio.com/$1 [R=301,L]

# SICURO
RewriteCond %{HTTP_HOST} !^www\.tuonegozio\.com$ [NC]
RewriteRule ^(.*)$ https://www.tuonegozio.com/$1 [R=301,L]

Rompere l'accesso al back office

# SICURO - escludere admin e API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteRule ^(.*)$ https://tuonegozio.com/it/$1 [R=301,L]

Testare i redirect in sicurezza

cp .htaccess .htaccess.backup
curl -I -L https://tuonegozio.com/vecchia-pagina.html

Dove posizionare le regole personalizzate

# I TUOI REDIRECT QUI (prima del blocco PrestaShop)
Redirect 301 /vecchia-pagina.html https://tuonegozio.com/nuova-pagina.html

# ~~start~~ Blocco PrestaShop
# ... regole auto-generate ...
# ~~end~~ Blocco PrestaShop

Quando usare un modulo

Considera un modulo di redirect quando personale non tecnico deve gestire i redirect, hai centinaia di redirect, o vuoi il rilevamento automatico dei 404.

Matrice di compatibilità delle versioni PHP per PrestaShop

Scegliere la versione PHP corretta per il tuo negozio PrestaShop è una delle decisioni infrastrutturali più critiche che prenderai. L'esecuzione di una versione PHP incompatibile può causare schermate bianche, processi di checkout malfunzionanti, errori nei moduli e vulnerabilità di sicurezza. Questa guida completa copre ogni versione di PrestaShop dalla 1.6 alla 9.x e associa ciascuna alle versioni PHP supportate, configurazioni raccomandate e considerazioni per l'aggiornamento.

Perché la versione PHP è importante per PrestaShop

PHP è il linguaggio lato server che alimenta PrestaShop. Ogni versione principale di PHP introduce miglioramenti delle prestazioni, nuove funzionalità del linguaggio e depreca le funzioni più vecchie. Il codice di PrestaShop si evolve parallelamente a PHP, il che significa che le versioni più recenti di PrestaShop sfruttano le funzionalità moderne di PHP abbandonando il supporto per quelle obsolete.

L'utilizzo della versione PHP sbagliata causa tre categorie di problemi:

• Errori fatali - Le funzioni rimosse nelle versioni PHP più recenti (ad es., le funzioni mysql_* rimosse in PHP 7.0, each() rimossa in PHP 8.0) causano crash immediati.
• Avvisi di deprecazione - Le funzioni deprecate generano avvisi che possono interrompere le risposte AJAX, l'output JSON e la generazione di PDF quando display_errors è abilitato.
• Esposizione a rischi di sicurezza - Le versioni PHP che hanno raggiunto la fine del ciclo di vita non ricevono più patch di sicurezza, lasciando il tuo negozio vulnerabile.

Matrice di compatibilità completa

PrestaShop 1.6.x

PHP raccomandato per 1.6.x - PHP 7.1. Offre il miglior equilibrio tra prestazioni e compatibilità. L'esecuzione di 1.6.x su PHP 7.2+ richiede modifiche ai file core che interrompono il percorso di aggiornamento e non è raccomandata.

PrestaShop 1.7.x

Avviso critico - Nessuna versione di PrestaShop 1.7 supporta PHP 8.0 o successivo. Se esegui PS 1.7.6 su PHP 8, Smarty si bloccherà immediatamente perché il motore dei template utilizza funzioni rimosse in PHP 8.0. La rimozione della funzione each() e i cambiamenti nel funzionamento di array_key_exists() con gli oggetti causano errori fatali.

PrestaShop 8.x

PHP raccomandato per 8.x - PHP 8.1. È il punto ottimale che offre piena compatibilità, supporto di sicurezza attivo ed eccellenti prestazioni con la compilazione JIT. PHP 8.1 introduce fibers, enums, proprietà readonly e tipi intersection che PrestaShop 8 può sfruttare.

PrestaShop 9.x

PHP raccomandato per 9.x - PHP 8.3 o 8.4. PrestaShop 9 funziona su Symfony 6.4 LTS e richiede PHP 8.1 come minimo. PHP 8.4 introduce i Property Hooks e la visibilità asimmetrica che i futuri aggiornamenti di PrestaShop sfrutteranno.

Date di fine vita PHP che devi conoscere

Se nel 2026 stai usando PHP 7.4 o 8.0, stai operando su una versione non supportata che non riceve più patch di sicurezza. Questo è un rischio critico per qualsiasi negozio e-commerce che gestisce dati di pagamento.

Come verificare la versione PHP attuale

Metodo 1 - Back Office PrestaShop

Naviga su Parametri avanzati > Informazioni. La sezione Informazioni sul server mostra la tua versione PHP, insieme al limite di memoria, tempo massimo di esecuzione e altre impostazioni pertinenti.

Metodo 2 - File PHP Info

Crea un file chiamato phpinfo.php nella directory root del tuo negozio con questo contenuto:

<?php phpinfo();

Accedilo tramite il tuo browser all'indirizzo https://tuonegozio.com/phpinfo.php. Elimina questo file immediatamente dopo la verifica - espone dettagli sensibili della configurazione del server.

Metodo 3 - Riga di comando

php -v
php -r "echo PHP_VERSION;"

Nota che la versione PHP CLI può differire dalla versione PHP del server web. Verifica sempre tramite l'interfaccia web o phpinfo().

Problemi comuni con la versione PHP sbagliata

Schermata bianca della morte (WSOD)

Il sintomo più comune di incompatibilità PHP. Controlla il log degli errori PHP (solitamente in /var/log/php-errors.log o accessibile tramite il pannello di hosting). Errori tipici:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Gli avvisi di deprecazione interrompono AJAX

Quando display_errors = On e aggiorni PHP, le notice di deprecazione vengono preposte alle risposte AJAX. Questo interrompe il parsing JSON nel back office, causando il fallimento silenzioso di funzionalità come la ricerca prodotti, la ricerca clienti e la creazione ordini. La soluzione:

; php.ini
display_errors = Off
log_errors = On
error_log = /percorso/verso/php-error.log

Incompatibilità dei moduli

I moduli di terze parti potrebbero non supportare la tua versione PHP. Prima di aggiornare PHP, verifica la compatibilità di ogni modulo installato. Aree problematiche comuni:

• Moduli che utilizzano create_function() - rimossa in PHP 8.0
• Moduli che utilizzano le funzioni mysql_* - rimosse in PHP 7.0
• Moduli che utilizzano l'accesso posizionale alle stringhe con parentesi graffe $str{0} - rimosso in PHP 8.0
• Moduli che non gestiscono i tipi di ritorno nullable - più rigorosi da PHP 8.1+

Come aggiornare PHP per PrestaShop in sicurezza

Passo 1 - Audit della configurazione attuale

Prima di modificare qualsiasi cosa, documenta il tuo ambiente attuale:

php -v                    # Versione PHP attuale
php -m                    # Estensioni caricate
php -i | grep memory      # Limite di memoria
php -i | grep max_exec    # Limite del tempo di esecuzione

Passo 2 - Verificare la compatibilità dei moduli

Esamina ogni modulo installato. Consulta la documentazione dello sviluppatore del modulo per il supporto delle versioni PHP. Se un modulo non è stato aggiornato da oltre due anni, è probabilmente incompatibile con PHP 8.x.

Passo 3 - Testare prima su staging

Non aggiornare mai PHP sul server di produzione senza test preliminari. Crea una copia staging del tuo negozio e testa con la nuova versione PHP. Verifica:

• Le pagine del front office si caricano correttamente
• Pagine prodotto, pagine categoria, pagine CMS
• Il processo di carrello e checkout si completa
• I moduli di pagamento elaborano le transazioni di test
• Le funzionalità del back office funzionano (modifica prodotti, gestione ordini)
• Tutti i moduli di terze parti funzionano correttamente
• I cron job vengono eseguiti senza errori

Passo 4 - Aggiornamento con piano di rollback

La maggior parte dei provider di hosting consente di cambiare la versione PHP dal pannello di controllo (cPanel, Plesk, DirectAdmin). Mantieni la versione PHP precedente disponibile per un rollback rapido se sorgono problemi.

Passo 5 - Svuotare tutte le cache dopo l'aggiornamento

Dopo il cambio di versione PHP, svuota ogni livello di cache:

# Svuotare la cache di PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Svuotare i template Smarty compilati
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Se usi OPcache, riavviare PHP-FPM
systemctl restart php8.3-fpm

# Svuotare la cache CDN (Cloudflare, ecc.)

Best practice di configurazione PHP per PrestaShop

Indipendentemente dalla versione PHP scelta, queste impostazioni sono essenziali per prestazioni ottimali di PrestaShop:

; Impostazioni php.ini raccomandate
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Impostazioni OPcache (critiche per le prestazioni)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Estensioni richieste
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Considerazioni per gli sviluppatori di moduli

Se sviluppi moduli PrestaShop, devi considerare attentamente la compatibilità PHP:

• Versione PHP minima - Punta a PHP 7.2 come minimo per moduli che devono funzionare su PrestaShop 8.0+, o PHP 8.1 per moduli esclusivi per PrestaShop 9.
• Usa PHPStan o Psalm - Gli strumenti di analisi statica rilevano le incompatibilità di versione PHP prima che lo facciano i tuoi utenti.
• Evita la sintassi specifica di versione - Funzionalità come le espressioni match (PHP 8.0), gli enums (PHP 8.1) e le proprietà readonly (PHP 8.1) limitano il tuo modulo a quelle versioni PHP e superiori.
• Testa su più versioni - Utilizza contenitori Docker con diverse versioni PHP per testare il tuo modulo su tutto l'intervallo di compatibilità.

Domande frequenti

Posso eseguire PrestaShop 1.7 su PHP 8?

No. Nessuna versione di PrestaShop 1.7 supporta ufficialmente PHP 8.0 o successivo. Sebbene alcuni utenti abbiano applicato patch per farlo funzionare parzialmente, questo non è supportato e causerà problemi con gli aggiornamenti. Il percorso corretto è migrare a PrestaShop 8.x.

Dovrei usare PHP 8.4 con PrestaShop 8.1?

Sconsigliato. PrestaShop 8.1 è stato sviluppato e testato principalmente con PHP 8.1. Sebbene PHP 8.2 sia parzialmente supportato nelle versioni 8.1.x successive, PHP 8.4 introduce cambiamenti che possono causare problemi con i componenti Symfony più vecchi. Resta con PHP 8.1 per PrestaShop 8.x.

Quanto è più veloce PHP 8.x rispetto a 7.x?

I benchmark mostrano che PHP 8.1 è circa il 20-30% più veloce di PHP 7.4 per i carichi di lavoro tipici di PrestaShop. Il compilatore JIT offre il maggior beneficio per le attività computazionali. Per le operazioni legate all'I/O (query al database, lettura di file), il miglioramento è minore ma comunque misurabile.

L'aggiornamento di PHP richiede l'aggiornamento di PrestaShop?

Non necessariamente, ma vanno di pari passo. Puoi aggiornare PHP nell'intervallo supportato per la tua versione di PrestaShop senza aggiornare PrestaShop stesso. Tuttavia, se vuoi utilizzare una versione PHP moderna (8.3+), avrai bisogno di PrestaShop 8.1 o 9.x.

What Content Security Policy Is and Why It Matters

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that tells the browser exactly which resources are allowed to load on your pages. It prevents cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities by giving you granular control over where JavaScript, CSS, images, fonts, frames, and other resources can originate from.

Without CSP, a browser will execute any JavaScript it encounters on your page, regardless of where it came from. If an attacker manages to inject a malicious script (through a vulnerable module, a compromised third-party library, or a stored XSS vulnerability), the browser happily executes it with full access to the page content, including customer data, form inputs, and session cookies.

With CSP, you declare a whitelist of trusted sources. If the browser encounters a resource that does not match the policy, it blocks it and logs a violation. This means that even if an attacker finds a way to inject code into your page, the browser refuses to execute it because it does not come from an approved source.

For PrestaShop stores that handle customer personal information, payment data, and authentication credentials, CSP is a critical security layer. It is not a replacement for fixing vulnerabilities in your code, but it is an effective defense-in-depth measure that limits the damage when a vulnerability exists.

CSP Directives Explained

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. The most important directives for PrestaShop are:

default-src: The fallback directive. If a more specific directive is not set, the browser uses default-src. Setting default-src 'self' means that by default, only resources from your own domain are allowed.

script-src: Controls where JavaScript can be loaded from. This is the most critical directive for XSS prevention. Common values include 'self' (your own domain), specific CDN domains, and analytics domains.

style-src: Controls where CSS can be loaded from. PrestaShop themes and modules frequently use inline styles, which means you may need 'unsafe-inline' unless you implement a nonce-based approach.

img-src: Controls where images can be loaded from. PrestaShop stores often load images from their own domain, CDN domains, and third-party services like Google (for user avatars or Maps).

font-src: Controls where fonts can be loaded from. Google Fonts, Font Awesome CDN, and your own domain are common sources.

connect-src: Controls which URLs can be contacted via JavaScript (AJAX requests, WebSocket connections, EventSource). Payment gateways, analytics endpoints, and your own API endpoints need to be listed here.

frame-src: Controls which domains can be embedded in iframes. Payment gateways like PayPal, Stripe, and Klarna use iframes for their payment forms. YouTube and Vimeo embeds also require frame-src entries.

frame-ancestors: Controls which domains can embed your page in an iframe. Setting frame-ancestors 'self' prevents clickjacking attacks by ensuring your store cannot be embedded in another site's iframe.

object-src: Controls plugin content like Flash. Set this to 'none' because Flash is obsolete and no PrestaShop functionality requires it.

base-uri: Controls which URLs can be used in the <base> element. Set to 'self' to prevent base URI manipulation attacks.

form-action: Controls which URLs forms can submit to. This should include your own domain and any external payment processing endpoints.

Starting with Report-Only Mode

Deploying CSP on a PrestaShop store requires careful preparation because an overly restrictive policy will break functionality. The right approach is to start with report-only mode, which tells the browser to report violations without actually blocking anything.

Instead of using the Content-Security-Policy header, use Content-Security-Policy-Report-Only. This header accepts the exact same directives but only generates reports without enforcing the policy. Your store continues to function normally while you collect data about what would be blocked.

Setting Up Violation Reporting

Add a report-uri directive to your policy that points to an endpoint that collects violation reports. You can use a free service like Report URI (report-uri.com), which provides a dashboard for viewing and analyzing CSP violations, or you can set up your own endpoint.

The browser sends violation reports as JSON POST requests. Each report includes the blocked URI, the directive that was violated, the page where the violation occurred, and other useful debugging information. Collecting these reports for a week or two on a live store gives you a comprehensive picture of all the resources your store loads and where they come from.

Building Your Initial Policy

Using the violation reports from report-only mode, build a whitelist of all legitimate resource sources. Group them by directive type. Your initial policy will likely include:

Your own domain for all resource types. CDN domains (like cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) for scripts, styles, and fonts. Analytics domains (like google-analytics.com, googletagmanager.com, connect.facebook.net) for tracking. Payment gateway domains for scripts, frames, and connections. Chat widget domains if you use live chat. Social media domains for embedded content or share buttons.

Building a CSP for PrestaShop

PrestaShop presents specific challenges for CSP implementation because of its architecture and the modules ecosystem.

Handling Inline Styles and Scripts

PrestaShop core, themes, and many modules use inline styles and inline JavaScript extensively. Inline code is blocked by default in CSP because an attacker who injects content into your page would be injecting inline code. There are three approaches to handling this:

Using 'unsafe-inline': The simplest but least secure approach. Adding 'unsafe-inline' to script-src and style-src allows all inline code, which significantly weakens CSP's XSS protection. For style-src, this is generally acceptable because inline styles pose a much lower security risk than inline scripts. For script-src, avoid 'unsafe-inline' if at all possible.

Using nonces: The recommended approach. A nonce is a random, single-use token generated on each request. You add the nonce to your CSP header (script-src 'nonce-abc123') and to each legitimate inline script tag (<script nonce="abc123">). The browser only executes inline scripts that have the correct nonce. Since the nonce changes on every request and an attacker cannot predict it, injected scripts without the nonce are blocked.

Implementing nonces in PrestaShop requires modifying the theme to add nonce attributes to all inline script tags and creating a mechanism (typically a module or a custom hook) that generates the nonce, adds it to the CSP header, and makes it available to templates. This is a significant implementation effort but provides strong XSS protection.

Using hashes: You can whitelist specific inline scripts by their SHA-256 hash. The browser computes the hash of each inline script it encounters and checks it against the hashes listed in the CSP. This approach works for inline scripts that do not change between requests (static inline scripts), but it is impractical for PrestaShop because many inline scripts include dynamic content like product IDs, prices, and user-specific data that change the hash.

Handling eval and Dynamic Code

Some JavaScript libraries use eval() or new Function() to dynamically create and execute code. CSP blocks these by default. If a module or library requires eval, you must add 'unsafe-eval' to script-src. Common culprits include older versions of jQuery templates, some analytics scripts, and certain payment gateway libraries.

Check your violation reports for entries with eval or inline as the blocked URI. These indicate code that uses dynamic evaluation. Where possible, replace the library with a version that does not use eval. When that is not possible (such as with a third-party payment gateway library you cannot modify), 'unsafe-eval' is the only option.

Third-Party Services

Most PrestaShop stores rely on multiple third-party services, each of which needs to be whitelisted in your CSP. Here are the most common ones and the directives they require:

Google Analytics and Google Tag Manager: These require entries in script-src for www.google-analytics.com, www.googletagmanager.com, and tagmanager.google.com. They also need connect-src entries for www.google-analytics.com and analytics.google.com (for sending tracking data), and img-src entries for www.google-analytics.com (for the tracking pixel). Google Tag Manager is particularly challenging because it dynamically loads scripts from domains you may not know in advance, as the scripts loaded depend on the tags configured in GTM.

PayPal: Requires script-src and frame-src entries for *.paypal.com and *.paypalobjects.com. The exact domains depend on whether you use PayPal Standard, PayPal Express, or the newer PayPal Commerce Platform integration.

Stripe: Requires script-src for js.stripe.com, frame-src for js.stripe.com and hooks.stripe.com, and connect-src for api.stripe.com.

Google Fonts: Requires style-src for fonts.googleapis.com and font-src for fonts.gstatic.com.

YouTube embeds: Require frame-src for www.youtube.com and www.youtube-nocookie.com.

Facebook Pixel and social plugins: Require script-src and connect-src for connect.facebook.net and www.facebook.com, plus img-src for www.facebook.com and *.fbcdn.net.

Live chat widgets (Tidio, Crisp, Intercom, etc.): Each has its own set of domains for scripts, styles, WebSocket connections, and images. Check your violation reports or the provider's documentation for the exact domains required.

A Complete CSP Example for PrestaShop

Here is a realistic CSP header for a PrestaShop store that uses Google Analytics, Google Fonts, PayPal, YouTube embeds, and has inline styles:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

This policy includes 'unsafe-inline' and 'unsafe-eval' for scripts, which weakens XSS protection but is necessary for most PrestaShop installations that have not been modified to support nonces. For img-src, the data: source is included because PrestaShop and many modules use data URIs for small images and icons.

Implementing CSP in PrestaShop

Via .htaccess (Apache)

For Apache servers, add the CSP header in your .htaccess file. Place it near the top of the file, before the PrestaShop rewrite rules:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

This requires the mod_headers module to be enabled. You can verify by checking if your server returns the header using browser DevTools (Network tab, click on the main document request, check the Response Headers).

Via Nginx Configuration

For Nginx, add the header in your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

The always parameter ensures the header is sent even for error responses, which is important because error pages can also be targets for XSS attacks.

Via a PrestaShop Module

Implementing CSP through a module gives you the ability to manage the policy from the back office. The module hooks into the actionOutputHTMLBefore or uses PHP's header() function in a front controller hook to add the CSP header to every response. A module-based approach is easier to maintain because you can update the policy without editing server configuration files and without restarting the web server.

Testing Your CSP with Browser DevTools

After implementing your CSP (in report-only mode initially), use browser DevTools to monitor for violations. Open the Console tab and look for messages that start with "[Report Only]" (in report-only mode) or "Refused to" (in enforcement mode). Each message tells you exactly what was blocked and which directive was responsible.

Test every page type on your store: the home page, category pages, product pages, the cart, the checkout process (including each step and each payment method), the customer account pages, and CMS pages. Each page type may load different resources, and you need to ensure your policy covers all of them.

Pay special attention to the checkout process. A blocked payment gateway script or iframe during checkout directly prevents customers from completing purchases. Test every payment method you offer, including the 3D Secure verification flow if applicable, because these often load additional resources from domains that are not obvious.

Common Testing Pitfalls

Testing in a development environment may not reveal all violations because your development setup may not include all the third-party services that run on production (analytics, advertising pixels, live chat, A/B testing tools). Always deploy CSP in report-only mode on production first and collect reports for at least one to two weeks before switching to enforcement.

Some violations only occur under specific conditions. For example, a payment gateway might load additional verification scripts only when a customer's card requires 3D Secure authentication. Social sharing buttons might load scripts only when a visitor clicks them. Dynamic content loaded via AJAX may reference resources that are not present on the initial page load. Run through every possible user flow during testing.

Gradual Enforcement Strategy

The recommended deployment strategy for CSP on PrestaShop follows these steps:

Phase 1: Discovery. Deploy a permissive Content-Security-Policy-Report-Only header with default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; and a report-uri. This logs all resources without blocking anything, giving you a complete inventory of what your store loads.

Phase 2: Draft policy. Based on the violation reports, build a whitelist policy that covers all legitimate resources. Deploy it in report-only mode and monitor for violations that indicate you missed a resource.

Phase 3: Refine. Over one to two weeks, check violation reports daily and add any legitimate sources you missed. Pay attention to reports that come from specific page types or user flows you might not have tested manually.

Phase 4: Enforce. Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri directive so you continue receiving violation reports. Monitor closely for the first week after enforcement to catch any legitimate resources that are being blocked.

Phase 5: Tighten. Once enforcement is stable, look for opportunities to tighten the policy. Can you replace 'unsafe-inline' in script-src with nonces? Can you narrow wildcard domains to specific subdomains? Can you remove sources that are no longer used? Each tightening step improves your security posture.

Maintaining Your CSP

A CSP is not a set-and-forget configuration. Every time you install a new module, add a third-party service, change payment gateways, or update your theme, you may need to update your CSP to include new resource sources. Make CSP review part of your module installation and update process.

Keep your report-uri active even after enforcement so you receive alerts about new violations. A sudden increase in violation reports might indicate that a module update introduced new resource requirements, or it might indicate an actual XSS attack attempt that your CSP is successfully blocking. Either way, you want to know about it.

Document your CSP and the reason for each entry. Over time, policies accumulate entries for services you no longer use. Periodic reviews to remove unnecessary entries keep the policy clean and reduce the attack surface. A CSP with fewer allowed sources is inherently more secure than one with many.

Come PrestaShop gestisce le immagini dei prodotti

Ogni immagine caricata su PrestaShop passa attraverso una pipeline di elaborazione. Quando aggiungi un'immagine prodotto, il sistema memorizza il file originale e poi genera diverse versioni ridimensionate chiamate miniature (thumbnail). Ogni miniatura corrisponde a un tipo di immagine definito nel back office sotto Design > Impostazioni immagini. Questi tipi di immagine specificano dimensioni esatte in pixel e sono legati a contesti specifici: elenchi prodotti, pagine prodotto, anteprime carrello, intestazioni categorie, loghi produttori e altro.

PrestaShop memorizza le immagini nella directory /img/. In PrestaShop 1.7 e 8.x, le immagini dei prodotti sono organizzate usando una struttura di directory basata sull'ID dell'immagine. Ad esempio, un'immagine con ID 1234 è memorizzata in /img/p/1/2/3/4/. All'interno di quella directory, troverai l'immagine originale (denominata per ID, come 1234.jpg) e tutte le miniature generate (come 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

La convenzione di denominazione segue il pattern: {image_id}-{image_type_name}.{extension}. Questo significa che ogni tipo di immagine che definisci crea un file aggiuntivo per ogni immagine prodotto nel tuo catalogo. Un negozio con 5.000 immagini prodotto e 8 tipi di immagine avrà circa 45.000 file di immagini (5.000 originali più 5.000 per 8 miniature). Questa scala è importante quando devi rigenerarle.

Comprendere i tipi di immagine

I tipi di immagine sono definiti nella tabella del database ps_image_type e gestiti tramite il back office. Ogni tipo di immagine ha un nome, larghezza, altezza e flag che indicano a quali tipi di entità si applica (prodotti, categorie, produttori, fornitori, negozi). L'installazione predefinita di PrestaShop include diversi tipi di immagine:

cart_default è tipicamente 125x125 pixel, usato nel carrello e nel mini carrello. small_default è circa 98x98 pixel, usato negli elenchi prodotti su alcuni temi. medium_default è circa 452x452 pixel, usato per le miniature dei prodotti nella pagina prodotto. home_default è circa 250x250 pixel, usato nella homepage e negli elenchi categorie. large_default è circa 800x800 pixel, usato come immagine principale del prodotto nella pagina prodotto.

I temi possono definire i propri requisiti per i tipi di immagine. Quando installi un nuovo tema, tipicamente registra i suoi tipi di immagine preferiti durante l'installazione. Il punto critico è che i file immagine effettivi su disco devono corrispondere a ciò che il tema si aspetta. Se il tema richiede home_default a 340x340 ma i tuoi file immagine sono stati generati a 250x250 perché usavi un tema diverso in precedenza, ogni elenco prodotti mostrerà immagini con dimensioni errate.

Quando la rigenerazione delle immagini è necessaria

Diverse situazioni richiedono una rigenerazione completa o parziale delle miniature. Comprendere quando è veramente necessaria ti risparmia l'esecuzione di un processo che può richiedere ore su cataloghi di grandi dimensioni.

Cambio tema

Questa è la ragione più comune. Temi diversi richiedono dimensioni immagine diverse. Quando passi da un tema a un altro, i template del nuovo tema fanno riferimento a tipi di immagine con dimensioni specifiche. Se quelle dimensioni non corrispondono ai file miniatura esistenti, le immagini appaiono stirate, ritagliate in modo errato o sfocate. Dopo aver installato un nuovo tema, controlla sempre i suoi requisiti per i tipi di immagine e rigenera le miniature per farle corrispondere.

Modifiche alle dimensioni del tipo di immagine

Se modifichi la larghezza o l'altezza di un tipo di immagine esistente tramite Design > Impostazioni immagini, la modifica influisce solo sulla definizione nel database. Tutti i file miniatura esistenti su disco mantengono le loro vecchie dimensioni. Devi rigenerare le miniature per il tipo di immagine modificato per applicare le nuove dimensioni alle immagini esistenti.

Aggiunta di un nuovo tipo di immagine

Quando crei un nuovo tipo di immagine, non esistono ancora file miniatura per esso. Se un template fa riferimento a questo nuovo tipo di immagine, mostrerà link immagine rotti fino a quando non rigeneri. Il processo di rigenerazione crea i file miniatura mancanti per ogni immagine esistente.

Problemi di qualità delle immagini

Se cambi l'impostazione della qualità di compressione JPEG in PrestaShop (che si trova in Prestazioni > Impostazioni immagini o nella sezione configurazione immagini a seconda della versione), le miniature esistenti sono state generate con la vecchia impostazione di qualità. La rigenerazione applica il nuovo livello di qualità a tutte le miniature.

Dopo una migrazione o spostamento del server

A volte durante la migrazione, i file miniatura vengono persi o corrotti mentre le immagini originali sopravvivono. Se le immagini dei prodotti appaiono rotte ma gli originali esistono nelle directory previste, la rigenerazione ricrea tutte le miniature dagli originali.

Abilitazione del formato WebP

PrestaShop 8.x ha introdotto il supporto WebP per le immagini dei prodotti. Quando abiliti la generazione WebP, le immagini esistenti non ottengono automaticamente le varianti WebP. Devi rigenerare le miniature per creare le versioni .webp accanto ai file JPEG o PNG esistenti.

Rigenerazione tramite il pannello di amministrazione

PrestaShop fornisce uno strumento di rigenerazione integrato nel back office sotto Design > Impostazioni immagini (o Preferenze > Immagini nelle versioni precedenti). In fondo alla pagina troverai la sezione di rigenerazione.

Opzioni disponibili

Puoi scegliere di cancellare le immagini precedenti prima della rigenerazione. Quando abilitato, PrestaShop elimina tutte le miniature esistenti prima di crearne di nuove. Questo è utile quando vuoi rimuovere miniature per tipi di immagine che non esistono più, ma significa che tutte le immagini saranno non disponibili durante il processo di rigenerazione. Quando disabilitato, PrestaShop sovrascrive le miniature esistenti e crea quelle mancanti senza eliminare nulla prima.

Puoi selezionare quali tipi di entità rigenerare: prodotti, categorie, produttori, fornitori o negozi. Se hai cambiato solo le dimensioni delle immagini dei prodotti, non c'è bisogno di rigenerare le immagini delle categorie o dei produttori.

Limitazioni dell'approccio tramite pannello di amministrazione

La rigenerazione tramite pannello di amministrazione viene eseguita come una richiesta web. Questo crea diversi problemi per cataloghi di grandi dimensioni. I server web hanno limiti di tempo di esecuzione, tipicamente da 30 a 300 secondi a seconda della configurazione. Un negozio con 10.000 immagini di prodotti e 8 tipi di immagine deve generare 80.000 file miniatura. Anche a un ritmo generoso di 10 immagini al secondo, ci vogliono più di due ore. La maggior parte dei server web terminerà il processo molto prima che finisca.

Si applicano anche i limiti di memoria. Ogni immagine deve essere caricata in memoria, ridimensionata usando GD o ImageMagick e salvata. Le immagini originali ad alta risoluzione possono consumare da 20 a 50 MB di memoria ciascuna durante l'elaborazione. Il limite di memoria predefinito di PHP di 128 MB o 256 MB può essere esaurito rapidamente, specialmente quando si elaborano immagini in sequenza senza una corretta pulizia della memoria.

Se il processo viene interrotto da un timeout o errore di memoria, ti ritrovi con un catalogo parzialmente rigenerato. Alcuni prodotti hanno le nuove miniature, altri hanno quelle vecchie e alcuni potrebbero non averne affatto. Questo stato incoerente è peggiore del problema originale.

Rigenerazione CLI per cataloghi di grandi dimensioni

Per negozi con più di qualche centinaio di prodotti, la rigenerazione da riga di comando è fortemente raccomandata. Bypassa i limiti di timeout del server web e può essere configurata con limiti di memoria più alti.

Utilizzo della console PrestaShop

PrestaShop 1.7.5 e versioni successive includono una console Symfony. Puoi rigenerare le miniature usando:

php bin/console prestashop:image:regenerate

Questo comando accetta diverse opzioni. Per rigenerare solo tipi di immagine specifici, usa il flag --image-type seguito dal nome del tipo di immagine. Per elaborare solo prodotti, categorie o altri tipi di entità specifici, usa il flag --entity. Il flag --format ti permette di specificare quali formati di output generare (jpg, png, webp).

Esegui il comando dalla directory root di PrestaShop. Se stai usando Docker, eseguilo all'interno del container:

docker exec -u www-data your-container php bin/console prestashop:image:regenerate

Il flag -u www-data assicura che i file generati siano di proprietà dell'utente del server web. Eseguire come root crea file che il server web non può servire o modificare successivamente.

Configurazione di memoria e tempo

Per l'esecuzione CLI, puoi aumentare i limiti PHP direttamente nel comando:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Impostare max_execution_time=0 rimuove completamente il limite di tempo, e 512 MB di memoria sono sufficienti per la maggior parte dei cataloghi. Per negozi con originali a risoluzione estremamente alta (4000x4000 pixel o più), potresti aver bisogno di 1 GB o più.

Approccio di rigenerazione personalizzato

Per cataloghi molto grandi (50.000 o più immagini), anche il comando della console può essere lento o problematico. Un approccio PHP personalizzato ti permette di elaborare le immagini in lotti con tracciamento del progresso, gestione degli errori e la possibilità di riprendere dopo un'interruzione.

L'approccio consiste nell'interrogare il database per tutti i record immagine, iterare attraverso di essi in lotti di 100 o 200, generare miniature per ogni immagine e registrare il progresso. Se il processo viene interrotto, puoi riprenderlo da dove si era fermato controllando quali miniature esistono già.

Un approccio a lotti permette anche di distribuire la rigenerazione su più esecuzioni durante le ore di minor traffico, evitando l'impatto sulle prestazioni del negozio attivo.

Generazione WebP durante la rigenerazione

WebP è un formato immagine moderno che fornisce dimensioni di file significativamente più piccole rispetto al JPEG a qualità comparabile. PrestaShop 8.x può generare versioni WebP delle miniature durante il processo di rigenerazione.

Abilitare il supporto WebP

Prima della rigenerazione, abilita WebP nella configurazione di PrestaShop. In PrestaShop 8.x, questa opzione si trova nelle impostazioni immagini. Quando abilitata, il processo di rigenerazione crea sia la miniatura tradizionale JPEG/PNG che una versione .webp per ogni tipo di immagine.

Requisiti del server

La generazione WebP richiede l'estensione GD compilata con supporto WebP (--with-webp) o l'estensione ImageMagick con delegati WebP. Puoi verificare il supporto GD con phpinfo() o gd_info(). Cerca WebP Support nell'output. Se il supporto WebP è mancante, il processo di rigenerazione salta silenziosamente la creazione WebP senza produrre errori.

Considerazioni sullo spazio su disco

I file WebP sono tipicamente dal 25 al 35 percento più piccoli dei file JPEG equivalenti, ma stai memorizzando entrambi i formati. Un negozio con 40.000 miniature JPEG che occupano 2 GB di spazio su disco avrà bisogno di circa 3,4 GB in totale dopo la generazione WebP (i 2 GB originali più circa 1,4 GB di file WebP). Pianifica di conseguenza il tuo spazio su disco prima di avviare una rigenerazione completa.

Servire WebP ai browser

Generare file WebP è solo metà della soluzione. Il tuo tema e server devono essere configurati per servire WebP ai browser che lo supportano, con fallback su JPEG/PNG per i browser che non lo fanno. Questo è tipicamente gestito tramite elementi <picture> nei template del tema o tramite la negoziazione del contenuto lato server usando l'header Accept.

In Apache, puoi aggiungere regole di rewrite che verificano il supporto WebP e servono la versione WebP quando disponibile. In Nginx, la direttiva try_files può verificare se esiste una versione .webp dell'immagine richiesta e servirla se l'header Accept del browser include image/webp.

Impatto sulle prestazioni e mitigazione

La rigenerazione delle immagini è intensiva per la CPU e pesante per l'I/O. Su un negozio attivo, può degradare significativamente le prestazioni se non gestita con attenzione.

Impatto sulla CPU

Ogni operazione di ridimensionamento immagine richiede il caricamento dell'originale in memoria, l'esecuzione dell'algoritmo di ridimensionamento, l'applicazione delle impostazioni di qualità/compressione e la scrittura del risultato su disco. L'operazione di ridimensionamento stessa è computazionalmente costosa, specialmente per immagini grandi ridotte a miniature piccole. Su un ambiente di hosting condiviso, questo può saturare la CPU e rallentare l'intero negozio.

Impatto sull'I/O

La rigenerazione legge ogni immagine originale e scrive diversi file miniatura. Su dischi rigidi tradizionali, questo crea un carico I/O significativo. Su storage SSD, l'impatto è molto minore ma comunque percepibile su larga scala. Il pattern I/O è particolarmente sfavorevole per i dischi rotanti perché comporta letture casuali (originali sparsi tra le directory) combinate con scritture sequenziali (miniature nelle stesse directory).

Eseguire la rigenerazione nelle ore di minor traffico

Programma la rigenerazione nel periodo di traffico più basso. Per i negozi europei, questo è tipicamente tra le 2:00 e le 6:00. Per negozi con traffico globale, potrebbe non esserci un vero momento di basso traffico, ma puoi identificare punti relativamente bassi dai tuoi dati di analytics.

Utilizzo di nice e ionice

Su server Linux, puoi ridurre la priorità del processo di rigenerazione in modo che non privi altri processi delle risorse. Il comando nice abbassa la priorità CPU, e ionice abbassa la priorità I/O:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Un valore nice di 19 è la priorità più bassa. La classe ionice 3 è la classe idle, il che significa che il processo ottiene tempo I/O solo quando nient'altro ne ha bisogno. Questo riduce drasticamente l'impatto sul negozio attivo ma rende la rigenerazione più lunga.

Scaling temporaneo

Se sei su un server cloud, considera di aumentare temporaneamente le risorse del server (più core CPU, più RAM, storage più veloce) per la durata della rigenerazione, per poi ridimensionare. Il costo extra di qualche ora di risorse di livello superiore è generalmente minimo rispetto all'impatto di una rigenerazione lenta e multi-giornaliera sulle prestazioni del negozio.

Evitare i timeout durante la rigenerazione

I timeout sono il problema più comune con la rigenerazione delle immagini. Ecco le impostazioni e configurazioni specifiche che li prevengono.

Configurazione PHP

La direttiva max_execution_time limita la durata di esecuzione di un processo PHP. Per l'esecuzione CLI, tipicamente è già impostata a 0 (illimitata), ma verifica controllando php -i | grep max_execution_time. Per la rigenerazione web tramite il pannello di amministrazione, aumenta questo valore nel tuo php.ini o .htaccess:

php_value max_execution_time 7200

Aumenta anche max_input_time se usi il pannello di amministrazione, poiché il timeout di invio del form è separato dal timeout di esecuzione:

php_value max_input_time 7200

Timeout del server web

La direttiva Timeout di Apache e proxy_read_timeout / fastcgi_read_timeout di Nginx possono terminare richieste di lunga durata anche se PHP stesso non è andato in timeout. Per Apache: Timeout 7200. Per Nginx, aggiungi al tuo blocco server: fastcgi_read_timeout 7200; o proxy_read_timeout 7200;.

Configurazione PHP-FPM

Se usi PHP-FPM (come la maggior parte delle configurazioni moderne), il request_terminate_timeout nella configurazione del pool può anche terminare processi di lunga durata. Impostalo a 0 per disabilitare il timeout, o adattalo al tempo massimo di esecuzione desiderato:

request_terminate_timeout = 7200

Timeout di Cloudflare e CDN

Se il tuo negozio è dietro Cloudflare o un altro CDN, il CDN ha il proprio timeout delle richieste (il piano gratuito di Cloudflare ha un timeout di 100 secondi). Questo rende la rigenerazione tramite pannello di amministrazione dietro un CDN effettivamente impossibile. Devi usare la rigenerazione CLI, bypassare il CDN per l'accesso admin, o usare una soluzione che elabori le immagini in modo asincrono.

Strategie di rigenerazione incrementale

La rigenerazione completa elabora ogni immagine nel catalogo. Per negozi con decine di migliaia di immagini, questo può richiedere molte ore. Gli approcci incrementali elaborano solo le immagini che necessitano effettivamente di nuove miniature.

Rigenerazione selettiva del tipo di immagine

Se hai aggiunto o modificato solo un tipo di immagine, non devi rigenerare tutti i tipi. Usa l'opzione --image-type nel comando della console per mirare solo al tipo di immagine specifico che è cambiato. Questo riduce il lavoro a un ottavo (o qualunque frazione dei tuoi tipi di immagine totali) di una rigenerazione completa.

Elaborazione basata sulla data

Se devi rigenerare le miniature solo per prodotti aggiunti di recente (ad esempio, dopo aver risolto un problema di elaborazione immagini), puoi interrogare il database per le immagini aggiunte dopo una data specifica ed elaborare solo quelle. La tabella ps_image non ha una colonna data per impostazione predefinita, ma la tabella associata ps_product ha i campi date_add e date_upd che possono essere usati per identificare i prodotti modificati di recente.

Rilevamento delle miniature mancanti

Invece di rigenerare tutto, scansiona le directory delle immagini per trovare immagini a cui mancano miniature specifiche e rigenera solo quelle. Questo è l'approccio più veloce quando hai aggiunto un nuovo tipo di immagine o quando una rigenerazione parziale è stata interrotta.

La logica è semplice: per ogni ID immagine nel database, verifica se il file miniatura previsto esiste su disco. Se non esiste, rigenera solo quella miniatura. Questo trasforma una rigenerazione completa di diverse ore in un processo mirato che potrebbe richiedere minuti.

Elaborazione parallela

Per cataloghi molto grandi, puoi dividere l'intervallo di ID immagine in blocchi ed elaborarli in parallelo usando più processi PHP. Ad esempio, un processo gestisce gli ID immagine da 1 a 10000, un altro da 10001 a 20000, e così via. Ogni processo funziona indipendentemente, e il throughput combinato è approssimativamente proporzionale al numero di processi paralleli (limitato dai core CPU e dalla larghezza di banda I/O).

Fai attenzione con l'elaborazione parallela e l'I/O disco. Eseguire troppi processi contemporaneamente su un disco rigido tradizionale causerà contesa I/O e rallenterà effettivamente le cose. Su storage SSD, da 4 a 8 processi paralleli funzionano tipicamente bene.

Considerazioni sul formato delle immagini

PrestaShop supporta JPEG, PNG e GIF come formati sorgente e può generare miniature in questi formati più WebP. Il formato sorgente influenza il comportamento della rigenerazione.

Immagini JPEG

JPEG è il formato più comune per le foto dei prodotti. Supporta la compressione lossy, il che significa che ogni volta che un JPEG viene salvato, si perde un po' di qualità. Questo è il motivo per cui rigenerare le miniature dagli upload originali produce risultati migliori rispetto alla rigenerazione da miniature precedentemente ridimensionate. Assicurati sempre di lavorare dall'immagine originale caricata, non da una miniatura precedentemente generata.

Immagini PNG

PNG supporta la trasparenza e la compressione lossless. Se le tue immagini prodotto usano sfondi trasparenti, le miniature PNG preservano quella trasparenza. Tuttavia, i file PNG sono tipicamente molto più grandi dei file JPEG. Considera se hai realmente bisogno della trasparenza. Se no, convertire le immagini prodotto PNG in JPEG durante la rigenerazione può ridurre significativamente lo spazio su disco e migliorare i tempi di caricamento delle pagine.

Gestione GIF

PrestaShop può accettare upload GIF, ma le miniature generate da sorgenti GIF sono statiche (l'animazione non viene preservata). Se hai immagini prodotto GIF animate, sappi che la rigenerazione produce miniature statiche dal primo frame.

Verifica post-rigenerazione

Dopo il completamento della rigenerazione, verifica i risultati prima di presumere che tutto sia corretto.

Controllo visivo della qualità delle immagini

Apri diverse pagine prodotto e ispeziona le immagini visivamente. Verifica che le miniature siano nitide, correttamente proporzionate e non stirate o pixelate. Presta particolare attenzione alle immagini che erano originalmente piccole (vicine o più piccole delle dimensioni della miniatura), poiché queste hanno più probabilità di mostrare problemi di qualità quando ingrandite.

Verifica del conteggio dei file

Confronta il numero di miniature generate con le aspettative. Se hai 5.000 immagini prodotto e 8 tipi di immagine, dovresti avere circa 40.000 file miniatura (più gli originali e potenzialmente le varianti WebP). Un conteggio significativamente inferiore indica che il processo di rigenerazione è stato interrotto o ha incontrato errori su alcune immagini.

Verifica dei permessi dei file

Verifica che i file rigenerati siano di proprietà dell'utente del server web (tipicamente www-data su Debian/Ubuntu o apache su CentOS). Se hai eseguito la rigenerazione come root, i file potrebbero non essere leggibili dal server web, causando immagini rotte nel frontend. Correggi con: chown -R www-data:www-data img/p/.

Pulizia della cache

Dopo la rigenerazione, pulisci tutte le cache. Questo include la cache interna di PrestaShop (Parametri avanzati > Prestazioni), qualsiasi cache opcode (OPcache), e qualsiasi cache CDN o reverse proxy. Le vecchie pagine cachate potrebbero ancora fare riferimento a vecchi URL o dimensioni delle immagini. Se usi un modulo che genera sprite CSS o immagini inline, rigenera anche quelli.

Se il tuo negozio è dietro Cloudflare, purga la cache per il percorso /img/ o fai un purge completo della cache. Cloudflare cacha le immagini aggressivamente, e i visitatori potrebbero vedere vecchie miniature fino alla scadenza o al purge della cache CDN.

Risoluzione dei problemi comuni di rigenerazione

Miniature nere o corrotte

Questo indica solitamente un problema con la libreria GD. L'estensione GD potrebbe non supportare il formato sorgente (ad esempio, GD compilato senza supporto JPEG). Verifica le capacità di GD con gd_info(). Un'altra causa è la memoria insufficiente: se PHP non può allocare abbastanza memoria per caricare l'immagine originale, GD potrebbe produrre un'immagine nera invece di generare un errore.

Dimensioni errate nelle miniature generate

Se le miniature hanno dimensioni inaspettate, controlla le definizioni dei tipi di immagine nel database. Il pannello di amministrazione potrebbe mostrare un valore mentre il database ne contiene un altro (questo può succedere dopo un import fallito o una modifica manuale del database). Interroga direttamente: SELECT * FROM ps_image_type WHERE name = 'home_default';

La rigenerazione si blocca senza progresso

Un processo di rigenerazione bloccato solitamente significa che ha incontrato un'immagine molto grande che ha esaurito la memoria disponibile. Controlla il log degli errori PHP per errori di allocazione memoria. La soluzione è aumentare il limite di memoria o pre-elaborare le immagini sorgente problematiche per ridurne la risoluzione prima della rigenerazione.

Errori di permesso negato

Se la rigenerazione riporta errori di permesso, il processo PHP non può scrivere nelle directory delle immagini. Questo accade comunemente in ambienti Docker dove i volumi bind-mounted hanno proprietà diverse all'interno e all'esterno del container. Assicurati che l'utente che esegue il comando di rigenerazione abbia accesso in scrittura all'intero albero della directory /img/.

Riepilogo

La rigenerazione delle immagini è un'attività di manutenzione che ogni proprietario di negozio PrestaShop incontra, solitamente durante un cambio tema o quando ottimizza le impostazioni delle immagini. Per cataloghi piccoli (sotto 500 prodotti), lo strumento del pannello di amministrazione funziona adeguatamente. Per qualsiasi cosa più grande, la rigenerazione CLI è l'unico approccio affidabile. I principi chiave sono: lavora sempre dalle immagini originali, adatta le definizioni dei tipi di immagine ai requisiti del tuo tema, gestisci proattivamente le risorse del server e i timeout, usa approcci incrementali quando possibile e verifica i risultati dopo il completamento del processo. Con WebP che sta diventando lo standard per le immagini web, la rigenerazione serve anche come meccanismo per creare varianti in formato moderno dell'intero catalogo prodotti, offrendo file di dimensioni ridotte e caricamenti pagina più rapidi ai tuoi clienti.

Cos'è Varnish e perché è importante per PrestaShop

Varnish Cache è un reverse proxy HTTP che si posiziona tra il tuo server web e internet, servendo copie cachate delle pagine senza mai toccare PHP o MySQL. Quando un visitatore richiede una pagina che Varnish ha in cache, la risposta arriva direttamente dalla memoria in microsecondi. PHP non viene eseguito. MySQL non riceve alcuna query. Il server web nota appena che la richiesta è avvenuta.

Questo è fondamentalmente diverso da come funzionano i moduli di full page cache (FPC) basati su PHP in PrestaShop. Un modulo FPC viene comunque eseguito all'interno di PHP. La richiesta raggiunge Apache o Nginx, PHP si avvia, PrestaShop si inizializza (caricando la configurazione, stabilendo connessioni al database, analizzando le rotte), e poi il modulo FPC intercetta la richiesta prima che la logica completa del controller venga eseguita, servendo un file HTML memorizzato nella cache. Sebbene sia significativamente più veloce rispetto al rendering della pagina da zero, comporta comunque l'avvio di PHP e il caricamento del framework PrestaShop. Questo overhead, tipicamente di 50-200 millisecondi anche per un cache hit, si accumula sotto carico.

Varnish elimina completamente questo overhead. Un cache hit di Varnish viene servito in 1-5 millisecondi. Con traffico elevato, la differenza è drammatica. Un negozio PrestaShop che fatica a gestire 100 utenti simultanei con un modulo FPC può servire migliaia di utenti simultanei con Varnish, perché la stragrande maggioranza delle richieste non raggiunge mai il backend PHP.

Quando i moduli PHP Full Page Cache sono sufficienti

Prima di investire in Varnish, vale la pena capire quando un modulo FPC basato su PHP è sufficiente. Per molti negozi PrestaShop, lo è.

Se il tuo negozio riceve meno di 50.000 visualizzazioni di pagina giornaliere, un modulo FPC ben configurato gestirà il carico senza problemi. La complessità aggiuntiva di Varnish non è giustificata quando il tuo server ha capacità di riserva. Se i tempi di risposta del server con FPC sono costantemente sotto i 200 millisecondi, i tuoi visitatori stanno già ottenendo caricamenti rapidi delle pagine. Il collo di bottiglia a quel punto è probabilmente il rendering frontend (CSS, JavaScript, immagini) piuttosto che il tempo di risposta del server.

I moduli FPC gestiscono alcuni scenari specifici di PrestaShop con più eleganza rispetto a Varnish perché vengono eseguiti all'interno dell'applicazione. Possono verificare se un utente è loggato, se il carrello contiene articoli e se determinati contenuti dinamici necessitano di personalizzazione — tutto all'interno dello stesso processo PHP. Con Varnish, questi controlli devono essere gestiti tramite l'ispezione dei cookie e regole di variazione della cache, il che aggiunge complessità alla configurazione.

Considera Varnish quando il tuo negozio gestisce regolarmente picchi di traffico (vendite flash, campagne marketing, picchi stagionali) che sovraccaricano la tua capacità PHP, quando hai bisogno di tempi di risposta inferiori a 10 ms per ragioni SEO o di esperienza utente, quando il budget per l'hosting è limitato e devi servire più traffico con lo stesso hardware, o quando il tuo negozio serve un'alta percentuale di navigazione anonima (pagine di categoria, pagine prodotto) rispetto all'attività del carrello e del checkout.

Come funziona Varnish: il flusso delle richieste

Comprendere il flusso delle richieste attraverso Varnish è essenziale per configurarlo correttamente con PrestaShop.

Arrivo della richiesta

Quando un visitatore richiede una pagina, la richiesta raggiunge prima Varnish (Varnish è in ascolto sulla porta 80 o 443 se la terminazione SSL è gestita da un proxy frontend). Varnish esamina la richiesta: l'URL, il metodo HTTP, i cookie e gli header.

Ricerca nella cache

Varnish controlla la sua cache alla ricerca di una risposta memorizzata che corrisponda a questa richiesta. La chiave della cache è tipicamente basata sull'URL e su header selezionati. Se una risposta corrispondente esiste e non è scaduta, Varnish la serve direttamente. Questo è un cache hit. La risposta viene inviata al visitatore e il server backend non viene mai contattato.

Cache miss

Se non esiste una risposta cachata corrispondente, Varnish inoltra la richiesta al server backend (Apache o Nginx che esegue PrestaShop). PrestaShop elabora la richiesta normalmente, genera la risposta HTML e la invia a Varnish. Varnish memorizza la risposta nella sua cache (se la risposta è cacheable) e la inoltra al visitatore. Le richieste successive per la stessa pagina verranno servite dalla cache.

Invalidazione della cache

Quando i dati del prodotto cambiano, i prezzi vengono aggiornati o il contenuto viene modificato, la versione in cache diventa obsoleta. Varnish deve essere informato di scartare la vecchia versione cachata in modo che ne recuperi una fresca dal backend. Questa è l'invalidazione della cache, ed è la parte più difficile di qualsiasi sistema di caching da implementare correttamente.

Configurazione VCL per PrestaShop

Varnish Configuration Language (VCL) è un linguaggio specifico di dominio che controlla come Varnish gestisce le richieste. Una configurazione VCL corretta per PrestaShop deve gestire diversi comportamenti specifici di PrestaShop.

Definizione del backend

La definizione del backend indica a Varnish dove inoltrare i cache miss. Per una tipica configurazione PrestaShop dove Apache o Nginx gira sullo stesso server sulla porta 8080:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

I timeout sono importanti. Le pagine PrestaShop possono richiedere diversi secondi per essere generate con cache fredda, specialmente le pagine di categoria con molti prodotti. Impostare first_byte_timeout troppo basso fa sì che Varnish restituisca un errore 503 prima che PrestaShop abbia finito di generare la pagina.

Gestione dei cookie e delle sessioni

I cookie sono la sfida più grande quando si fa caching di PrestaShop con Varnish. PrestaShop imposta diversi cookie per impostazione predefinita, e Varnish tratta qualsiasi richiesta con cookie come non cacheable a meno che non venga istruito diversamente. Se non gestisci i cookie nel tuo VCL, Varnish non cacheerà praticamente nulla.

PrestaShop imposta questi cookie sulla maggior parte delle richieste: il cookie di sessione (tipicamente chiamato PrestaShop-xxxx), i cookie relativi al carrello, i cookie di Google Analytics (_ga, _gid, _gat) e vari cookie di tracciamento da strumenti di marketing. Di questi, solo il cookie di sessione PrestaShop è importante per il comportamento della cache. I cookie di analytics e tracciamento dovrebbero essere rimossi dalla richiesta prima della ricerca nella cache in modo che non impediscano il caching.

Nella subroutine VCL vcl_recv, rimuovi i cookie non essenziali:

sub vcl_recv {
  # Rimuovi cookie di Google Analytics e altri traccianti
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Rimuovi header cookie vuoto
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Decidere cosa cachare

Non tutte le pagine PrestaShop dovrebbero essere cachate. Il VCL deve distinguere tra richieste cacheable e non cacheable.

Cacha sempre: Pagine prodotto per visitatori anonimi, pagine di elenco categorie, pagine CMS (chi siamo, termini, contatti), la homepage, pagine di produttori e fornitori, pagine della sitemap.

Non cachare mai: La pagina del carrello, le pagine del checkout (tutti i passaggi), l'area account cliente (ordini, indirizzi, informazioni personali), le pagine di login e registrazione, qualsiasi pagina per un cliente loggato, richieste POST, richieste AJAX che modificano lo stato (aggiungi al carrello, aggiorna quantità).

La logica VCL per questo tipicamente controlla il percorso URL e la presenza di cookie di sessione:

sub vcl_recv {
  # Non cachare le richieste POST
  if (req.method == "POST") {
    return (pass);
  }
  # Non cachare l'area admin
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Non cachare checkout e carrello
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Non cachare se il cliente ha articoli nel carrello
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Impostare la durata della cache

Nella subroutine vcl_backend_response, controlli per quanto tempo Varnish cacha ogni risposta. PrestaShop invia header Cache-Control che tipicamente indicano no-cache o private perché presume che ogni risposta possa contenere contenuto personalizzato. Devi sovrascriverli per le pagine che sai essere sicure da cachare:

sub vcl_backend_response {
  # Cacha pagine prodotto e categoria per 1 ora
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Cacha asset statici per 1 giorno
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Rimuovere Set-Cookie dalle risposte cachate è critico. Se una risposta cachata include un header Set-Cookie, Varnish non la cacheerà per impostazione predefinita, e anche se forzato a cachare, imposterebbe lo stesso cookie di sessione per ogni visitatore, causando session hijacking.

Invalidazione della cache con richieste PURGE

Quando il prezzo di un prodotto cambia, viene aggiunto un nuovo prodotto o il contenuto viene aggiornato, la versione cachata deve essere invalidata. Varnish supporta le richieste PURGE: un metodo HTTP speciale che indica a Varnish di rimuovere un URL specifico dalla sua cache.

Configurare il supporto PURGE

Aggiungi la gestione PURGE al tuo VCL:

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    return (purge);
  }
}

L'ACL limita le richieste PURGE a localhost, impedendo agli utenti esterni di svuotare la tua cache.

Attivare i purge da PrestaShop

PrestaShop non invia nativamente richieste PURGE. Hai bisogno di un modulo o di un hook personalizzato che rilevi quando il contenuto cacheable cambia e invii una richiesta PURGE a Varnish. Il modulo si aggancia agli eventi PrestaShop come actionProductUpdate, actionCategoryUpdate e actionCMSPageUpdate. Quando questi eventi si attivano, il modulo invia una richiesta HTTP PURGE all'URL corrispondente sul server Varnish.

Per un aggiornamento di prodotto, il modulo dovrebbe purgare l'URL del prodotto, gli URL delle categorie a cui appartiene il prodotto (perché le pagine elenco delle categorie mostrano prezzi e disponibilità dei prodotti) e potenzialmente la homepage se mostra prodotti in evidenza. Questa cascata di purge è necessaria per evitare che dati obsoleti appaiano in qualsiasi punto del sito.

Invalidazione basata su BAN

Per scenari in cui molti URL devono essere purgati contemporaneamente (un aggiornamento prezzi a livello di sito, un cambio di design, un nuovo banner promozionale), le singole richieste PURGE sono impraticabili. Varnish supporta i ban, che sono regole di invalidazione basate su pattern. Un ban indica a Varnish di scartare qualsiasi oggetto cachato che corrisponda a un pattern:

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Banned."));
  }
}

Inviare una richiesta BAN con l'header X-Ban-Pattern: /category/ invaliderebbe tutte le pagine di categoria cachate in un'unica operazione.

Edge Side Includes (ESI) per blocchi dinamici

Molte pagine PrestaShop contengono un mix di contenuto statico e dinamico. L'elenco prodotti in una pagina di categoria è lo stesso per ogni visitatore, ma l'header che mostra il conteggio del carrello è personalizzato. Senza ESI, non puoi cachare la pagina affatto perché l'header dinamico rende l'intera risposta specifica per il visitatore.

Gli Edge Side Includes risolvono questo problema permettendo di contrassegnare sezioni della pagina come frammenti recuperati separatamente. Varnish assembla la pagina finale da frammenti cachati e non cachati.

Come funziona ESI

Nel tuo template Smarty, invece di renderizzare direttamente il widget del carrello, includi un tag ESI:

<esi:include src="/module/cartwidget/ajax" />

Quando Varnish elabora la pagina cachata, incontra il tag ESI e effettua una richiesta separata al backend per quel frammento. Il corpo principale della pagina viene servito dalla cache, mentre il widget del carrello viene recuperato fresco da PrestaShop. La risposta assemblata include sia il corpo cachato che il widget del carrello aggiornato.

Abilita l'elaborazione ESI nel tuo VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

Considerazioni ESI per PrestaShop

Implementare ESI richiede la modifica dei template PrestaShop per separare il contenuto dinamico in frammenti compatibili con ESI. Ogni frammento necessita del proprio endpoint URL che restituisce solo l'HTML per quel blocco. I frammenti che sono tipicamente dinamici e necessitano di trattamento ESI includono il widget riepilogo carrello (conteggio articoli, totale), il saluto al cliente ("Ciao, Giovanni"), eventuali raccomandazioni di prodotti personalizzate, il link login/logout e i prodotti visualizzati di recente.

Lo sforzo richiesto per implementare ESI correttamente è significativo. Ogni frammento dinamico necessita di un controller dedicato, i template richiedono ristrutturazione e le regole di caching per ogni frammento necessitano di regolazione individuale. Questo è uno dei motivi per cui Varnish è considerato un'ottimizzazione avanzata — funziona meglio quando l'applicazione è progettata tenendolo a mente.

Controlli di salute del backend

Varnish può monitorare lo stato del tuo server backend e agire quando diventa non disponibile. Questo viene configurato nella definizione del backend:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish invia una richiesta a /ping.php ogni 5 secondi. Se 3 degli ultimi 5 controlli falliscono, Varnish contrassegna il backend come malato. Mentre il backend è malato, Varnish può servire contenuto cachato obsoleto (modalità grace) invece di restituire errori ai visitatori. Questo significa che il tuo negozio rimane parzialmente disponibile anche quando il backend PHP va in crash o si riavvia.

La configurazione della modalità grace determina per quanto tempo Varnish servirà contenuto obsoleto:

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Con un grace di 6 ore, se il tuo backend va giù, i visitatori vedranno pagine cachate (anche se vecchie di 6 ore) invece di pagine di errore. I prezzi dei prodotti potrebbero essere leggermente non aggiornati, ma il negozio resta funzionante mentre risolvi il problema del backend.

Benchmark delle prestazioni

La differenza di prestazioni tra nessuna cache, PHP FPC e Varnish è sostanziale e misurabile.

Senza cache (PrestaShop base): Una tipica pagina prodotto PrestaShop richiede 200-800 millisecondi per essere generata, a seconda dell'hardware del server, del numero di moduli caricati e del numero di query al database. Sotto carico, i tempi di risposta aumentano perché i worker PHP sono saturi. Un singolo server può gestire 20-50 utenti simultanei prima che i tempi di risposta diventino inaccettabili.

Modulo PHP FPC: I cache hit vengono serviti in 30-100 millisecondi perché PHP si avvia comunque e il framework si inizializza parzialmente. Sotto carico, le prestazioni sono molto migliori perché le risposte cachate richiedono un tempo di elaborazione PHP minimo. Un singolo server può gestire 200-500 utenti simultanei a seconda della configurazione. I cache miss richiedono comunque il tempo completo di rendering.

Varnish: I cache hit vengono serviti in 1-5 millisecondi. Sotto carico, Varnish stesso può gestire migliaia di connessioni simultanee perché è scritto in C ed è progettato specificamente per questo tipo di carico. Il server backend gestisce solo i cache miss, che sono una piccola frazione del traffico totale in un sistema correttamente configurato. Lo stesso hardware che fatica con 50 utenti simultanei senza caching può gestirne 5.000 o più con Varnish.

Questi numeri illustrano perché Varnish vale la complessità di configurazione per i negozi ad alto traffico. Il miglioramento delle prestazioni non è incrementale — è di un ordine di grandezza.

Requisiti di hosting

Varnish ha requisiti di hosting specifici che non tutti gli ambienti di hosting PrestaShop possono soddisfare.

Accesso al server

Hai bisogno dell'accesso root per installare e configurare Varnish. I piani di hosting condiviso non supportano Varnish perché richiede un proprio processo in ascolto su una porta che intercetta tutto il traffico HTTP. Hai bisogno di un VPS, server dedicato o istanza cloud dove controlli l'intero stack del server.

Memoria

Varnish memorizza la sua cache nella RAM. La quantità di RAM necessaria dipende dal numero di pagine uniche nel tuo catalogo e dalla dimensione di ogni risposta cachata. Una formula approssimativa: il numero di pagine cacheabili moltiplicato per la dimensione media della pagina fornisce la dimensione minima della cache. Un negozio con 5.000 prodotti, 200 categorie e una dimensione media della pagina di 50KB necessita di circa 260MB di cache RAM. Aggiungi l'overhead per Varnish stesso e dovresti allocare almeno 512MB. Per cataloghi più grandi, 1-2GB è la norma.

Configurazione delle porte

In una configurazione standard, Varnish è in ascolto sulla porta 80 (la porta HTTP predefinita) e inoltra i cache miss al server web su una porta diversa (comunemente 8080). Questo significa che devi riconfigurare Apache o Nginx per ascoltare sulla porta 8080 invece che sulla 80. Se usi HTTPS (e dovresti), tipicamente metti Nginx davanti a Varnish per gestire la terminazione SSL: Nginx sulla porta 443 termina SSL e inoltra a Varnish sulla porta 80, che inoltra i cache miss ad Apache o PHP-FPM sulla porta 8080.

Esempio di configurazione Docker

Eseguire Varnish in Docker insieme a un container PrestaShop è un modo pulito per aggiungere Varnish a una configurazione esistente senza modificare il sistema host.

Configurazione Docker Compose

Una configurazione Docker Compose di base con Varnish, Nginx per SSL e PrestaShop:

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

In questa configurazione, Varnish è il punto di ingresso sulla porta 80. Il container PrestaShop non espone la sua porta all'host, solo alla rete Docker. L'host del backend VCL sarebbe prestashop (il nome del servizio Docker) sulla porta 80.

VCL per Docker

La definizione del backend VCL per Docker usa il nome del servizio invece di localhost:

backend default {
  .host = "prestashop";
  .port = "80";
}

Il DNS interno di Docker risolve il nome del servizio nell'IP del container. Il resto della configurazione VCL rimane lo stesso di una configurazione senza Docker.

Storage della cache in Docker

Per impostazione predefinita, l'immagine Docker di Varnish usa lo storage in memoria (malloc), che è ideale per le prestazioni. La variabile d'ambiente VARNISH_SIZE controlla quanta memoria Varnish alloca per la sua cache. Imposta questo valore su uno che rientri nei limiti di memoria del tuo container lasciando spazio per il processo Varnish stesso.

Per una cache persistente che sopravviva ai riavvii del container, puoi usare lo storage basato su file montando un volume, ma è raramente necessario. La cache si scalda rapidamente (entro pochi minuti dalla ricezione del traffico) e lo storage su file è più lento di quello in memoria.

Monitoraggio delle prestazioni di Varnish

Varnish fornisce strumenti integrati per monitorare le prestazioni della cache.

Il comando varnishstat mostra statistiche in tempo reale incluso il tasso di hit della cache, le connessioni al backend e l'utilizzo della memoria. La metrica più importante è il tasso di hit, che dovrebbe essere dell'85% o superiore per una configurazione ben configurata. Se il tuo tasso di hit è sotto il 70%, rivedi le regole VCL perché troppe richieste passano al backend.

Il comando varnishlog mostra log dettagliati per ogni richiesta, che sono inestimabili per il debug del motivo per cui specifiche richieste non vengono cachate. Puoi filtrare per pattern URL, codice di risposta o stato di cache hit/miss.

Il comando varnishtop mostra una lista classificata delle voci di log più frequenti, aiutandoti a identificare pattern nei cache miss o negli errori.

Errori comuni

Dimenticare di rimuovere i cookie

La configurazione errata più comune di Varnish con PrestaShop è non rimuovere i cookie di analytics e tracciamento. Questi cookie sono presenti in praticamente ogni richiesta e rendono ogni richiesta unica dal punto di vista di Varnish, risultando in un tasso di hit dello 0%. Rimuovi sempre i cookie che non ti servono per la variazione della cache.

Cachare contenuto personalizzato

Se il tuo VCL è troppo aggressivo, cacherà pagine che contengono contenuto personalizzato (saluto dell'utente loggato, contenuto del carrello) e le servirà ad altri visitatori. Questo causa seri problemi di usabilità e potenziali problemi di privacy. Passa sempre le richieste che contengono cookie di sessione al backend.

Non invalidare ai cambi di contenuto

Senza un meccanismo di purging adeguato, le modifiche al contenuto nel back office non saranno visibili fino alla scadenza naturale delle pagine cachate. Per un negozio con cambiamenti attivi dell'inventario, questo significa che i visitatori potrebbero vedere prodotti esauriti, prezzi sbagliati o descrizioni obsolete. Implementa il supporto PURGE o BAN e integralo con gli hook di aggiornamento di PrestaShop.

Ignorare HTTPS

Varnish non gestisce SSL nativamente. Devi mettere un proxy di terminazione SSL (Nginx, HAProxy o un load balancer cloud) davanti a Varnish. Non pianificare questo nella tua architettura porta a problemi di contenuto misto (mixed content), loop di redirect o l'impossibilità di servire traffico HTTPS.

Varnish è adatto al tuo negozio?

Varnish è uno strumento potente, ma non è la scelta giusta per ogni negozio PrestaShop. Aggiunge complessità operativa: un altro servizio da monitorare, un altro linguaggio di configurazione da imparare, un altro livello nel tuo processo di debug. I benefici sono chiari e misurabili per i negozi che ne hanno bisogno, ma comportano un costo in termini di tempo di setup, manutenzione e difficoltà di troubleshooting.

Se il tuo negozio serve meno di 50.000 visualizzazioni di pagina al giorno e il tuo server gestisce il carico comodamente con un modulo FPC, Varnish è complessità non necessaria. Se il tuo negozio affronta regolarmente picchi di traffico che sovraccaricano il server, serve un alto volume di traffico di navigazione anonima o necessita dei tempi di risposta più rapidi possibili per SEO o esperienza utente, Varnish fornisce un livello di prestazioni che nessuna soluzione di caching basata su PHP può eguagliare.

Inizia con una corretta ottimizzazione di PrestaShop (ottimizzazione delle query, audit dei moduli, PHP OPcache, ottimizzazione delle immagini) e un modulo FPC. Se queste ottimizzazioni non bastano, Varnish è il passo successivo nella scala del performance scaling.