Risoluzione problemi FAQ

Il problema: hai bisogno del modulo, ma non delle sue risorse su ogni pagina

Ci sono molte situazioni in cui vuoi mantenere un modulo PrestaShop installato e attivo ma impedirgli di caricare i suoi file CSS o JavaScript su pagine specifiche, o addirittura su tutte le pagine. Forse hai un modulo di cui hai bisogno della funzionalità ma il cui stile è in conflitto con il tuo tema. Forse un modulo carica una libreria JavaScript pesante che hai già incluso attraverso il tuo tema. Forse vuoi sostituire gli stili predefiniti di un modulo con il tuo CSS personalizzato senza che gli stili originali interferiscano. Oppure forse hai identificato attraverso un audit delle prestazioni che un modulo carica risorse su pagine dove non ha alcun output visibile e vuoi eliminare quello spreco.

Disinstallare il modulo non è un'opzione perché hai bisogno delle sue funzionalità principali: i suoi hook, le sue tabelle nel database, la sua configurazione, le sue funzionalità nel back office. Devi semplicemente rimuovere chirurgicamente specifici file CSS o JavaScript dall'output del front office. PrestaShop fornisce diversi meccanismi per raggiungere questo obiettivo, e questo articolo li copre tutti in dettaglio, dal più semplice al più potente.

Metodo 1: Utilizzare Theme.yml per rimuovere le risorse dei moduli

Il modo più semplice e manutenibile per rimuovere i CSS o JavaScript di un modulo in PrestaShop 1.7 e versioni successive è attraverso il file di configurazione del tema, theme.yml. Questo file, situato nella directory radice del tuo tema, controlla quali risorse carica il tema e quali risorse dei moduli vengono rimosse.

Apri il tuo file theme.yml e cerca la sezione assets. Se non esiste, puoi crearla. All'interno della sezione assets, puoi specificare i file CSS e JavaScript da rimuovere tramite il loro ID risorsa. Ogni risorsa registrata attraverso registerStylesheet o registerJavascript ha un ID, che tipicamente è il nome del modulo seguito da un suffisso descrittivo.

Per trovare gli ID delle risorse utilizzati da un modulo, ispeziona il codice sorgente della tua pagina e cerca i tag link dei fogli di stile e gli elementi script. PrestaShop aggiunge un attributo id a questi elementi in modalità debug, oppure puoi trovare gli ID nel codice sorgente del modulo dove chiama registerStylesheet o registerJavascript.

Nel tuo file theme.yml, aggiungi una sezione sotto assets, poi css, poi all. Aggiungi una voce con l'ID della risorsa e impostalo su false. Ad esempio, se un modulo registra un foglio di stile con l'ID modulename-style, aggiungeresti modulename-style con un valore false sotto la sezione css all. Fai lo stesso per i file JavaScript sotto la sezione js all.

Dopo aver modificato theme.yml, devi svuotare la cache di PrestaShop da Parametri Avanzati, Prestazioni. Le modifiche a theme.yml hanno effetto dopo la ricostruzione della cache. Questo approccio persiste attraverso gli aggiornamenti del modulo perché la rimozione è definita nel tuo tema, non nel modulo stesso. Tuttavia, rimuove le risorse da tutte le pagine. Se hai bisogno delle risorse su alcune pagine ma non su altre, avrai bisogno di un approccio più mirato.

Metodo 2: Media::unregisterStylesheet e Media::unregisterJavascript

PrestaShop 1.7 ha introdotto i metodi della classe Media unregisterStylesheet e unregisterJavascript, che consentono di rimuovere programmaticamente specifiche risorse registrate da altri moduli. Questi metodi sono potenti perché puoi chiamarli in modo condizionale, rimuovendo le risorse solo su pagine specifiche mantenendole sulle altre.

Per utilizzare questo approccio, hai bisogno di un modulo personalizzato o di una modifica a un modulo esistente. Nel metodo hookActionFrontControllerSetMedia del tuo modulo, chiama Media::unregisterStylesheet con l'ID della risorsa del file CSS che vuoi rimuovere. Analogamente, chiama Media::unregisterJavascript con l'ID della risorsa del file JavaScript. Puoi racchiudere queste chiamate in logica condizionale per rimuovere le risorse solo su specifici tipi di pagina.

Ad esempio, se vuoi rimuovere le risorse di un modulo slider da ogni pagina eccetto la homepage, verificheresti se il controller corrente è IndexController. Se non è la homepage, chiami i metodi di deregistrazione. Se è la homepage, non fai nulla e lasci che le risorse si carichino normalmente.

La considerazione chiave con questo approccio è l'ordine di esecuzione degli hook. Il hookActionFrontControllerSetMedia del tuo modulo deve essere eseguito dopo il modulo di cui vuoi rimuovere le risorse. PrestaShop esegue i callback degli hook nell'ordine in cui i moduli sono registrati sull'hook, che puoi controllare attraverso la pagina Design, Posizioni nel back office. Sposta il tuo modulo personalizzato sotto il modulo target sull'hook actionFrontControllerSetMedia per assicurarti che le tue chiamate di deregistrazione avvengano dopo che il modulo target ha registrato le sue risorse.

Se il modulo problematico utilizza i vecchi metodi addCSS e addJS invece di registerStylesheet e registerJavascript, i metodi di deregistrazione potrebbero non funzionare perché i vecchi metodi non utilizzano lo stesso sistema di gestione delle risorse. In quel caso, hai bisogno di un approccio diverso.

Metodo 3: Modulo personalizzato per bloccare risorse specifiche

Quando hai bisogno di un controllo granulare su quali risorse si caricano su quali pagine, creare un modulo dedicato alla gestione delle risorse è la soluzione più flessibile. Questo modulo funge da punto centrale dove definisci le regole per bloccare o consentire specifiche risorse dei moduli.

Crea un nuovo modulo con un metodo hookActionFrontControllerSetMedia. All'interno di questo metodo, definisci un array di regole per le risorse. Ogni regola specifica il nome di un modulo, gli ID delle risorse da bloccare e le condizioni in base alle quali bloccarle. Le condizioni possono essere basate sul nome del controller, sul tipo di pagina o su qualsiasi altro criterio disponibile nel contesto PrestaShop.

Il tuo modulo scorre le regole a ogni caricamento di pagina, verifica le condizioni e chiama Media::unregisterStylesheet o Media::unregisterJavascript per ogni risorsa che dovrebbe essere bloccata sulla pagina corrente. Questo approccio centralizzato è molto più facile da mantenere rispetto a distribuire la logica di rimozione delle risorse tra più moduli o file del tema.

Puoi migliorare questo modulo con una pagina di configurazione nel back office che ti permette di gestire le regole attraverso l'interfaccia di amministrazione di PrestaShop invece di modificare il codice. Un semplice modulo con campi per il nome del modulo, l'ID della risorsa e un multiselect per i tipi di pagina dove la risorsa dovrebbe essere bloccata ti offre un modo intuitivo per gestire il caricamento delle risorse senza toccare il codice dopo la configurazione iniziale.

Questo approccio funziona sia con il nuovo sistema registerStylesheet sia con il vecchio sistema addCSS, anche se potresti dover utilizzare tecniche diverse per ciascuno. Per le risorse registrate con il nuovo sistema, usa i metodi Media::unregister. Per le risorse aggiunte con il vecchio sistema, puoi manipolare direttamente gli array css_files e js_files del controller nel metodo hookActionFrontControllerSetMedia.

Metodo 4: L'approccio di sganciamento dall'hook

Un approccio più aggressivo ma talvolta necessario è sganciare completamente un modulo dagli hook dove registra le sue risorse. Vai su Design, quindi Posizioni nel tuo back office. Trova il modulo sull'hook displayHeader o actionFrontControllerSetMedia. Clicca sul pulsante elimina o sgancia per rimuovere il modulo da quell'hook completamente.

Questo impedisce al modulo di caricare qualsiasi risorsa, su qualsiasi pagina. Gli altri hook del modulo, come displayProductAdditionalInfo o displayFooter, continuano a funzionare normalmente. Tuttavia, l'output del modulo sul front office potrebbe rompersi se dipende dai suoi CSS per lo stile o dai suoi JavaScript per il comportamento interattivo.

Questo approccio è più utile quando prevedi di sostituire interamente lo stile del modulo con il tuo CSS personalizzato. Sganci il modulo da displayHeader per impedire il caricamento del suo CSS, poi scrivi i tuoi stili nel file CSS personalizzato del tuo tema che puntano agli elementi HTML del modulo. Questo ti dà il controllo completo sull'aspetto del modulo senza alcun conflitto tra gli stili originali e le tue personalizzazioni.

Per il JavaScript, lo sganciamento è più rischioso. Se il modulo si basa sul suo JavaScript per funzionalità core come chiamate AJAX, validazione dei form o caricamento dinamico dei contenuti, rimuovere il JavaScript romperà quelle funzionalità. Sgancia il JavaScript solo se sei certo che l'output del modulo sul front office non dipenda da esso, o se stai fornendo un'implementazione sostitutiva attraverso il tuo tema.

Un'avvertenza importante: se aggiorni il modulo, il processo di aggiornamento potrebbe ri-registrare il modulo sugli hook da cui lo avevi rimosso. Dopo ogni aggiornamento del modulo, controlla Design, Posizioni per verificare che il tuo sganciamento sia ancora attivo. Alcuni moduli registrano esplicitamente i loro hook durante il processo di aggiornamento, il che sovrascrive il tuo sganciamento manuale.

Metodo 5: Sovrascrivere le risorse dei moduli attraverso il tema

Il sistema di temi di PrestaShop consente di sovrascrivere i file template dei moduli posizionandoli nella directory modules del tuo tema. Sebbene questo sia utilizzato principalmente per le sovrascritture dei template, puoi anche usarlo per controllare indirettamente il caricamento delle risorse.

Se un modulo carica le sue risorse attraverso i suoi file template utilizzando funzioni Smarty come tag script o stylesheet direttamente nei file TPL piuttosto che attraverso hook PHP, puoi sovrascrivere quei template nel tuo tema e rimuovere i riferimenti alle risorse. Copia il file template del modulo nella directory modules del tuo tema, mantenendo la stessa struttura di directory, e modifica la copia per rimuovere i riferimenti CSS o JavaScript indesiderati.

Questo approccio è specifico del tema, il che significa che influisce solo sul tema corrente. Se cambi tema, le sovrascritture non si trasferiscono. Richiede anche manutenzione: quando il modulo aggiorna i suoi template, devi aggiornare le tue sovrascritture per corrispondere a eventuali modifiche strutturali mantenendo le tue modifiche di rimozione delle risorse.

Per i moduli che caricano risorse attraverso hook PHP piuttosto che template, le sovrascritture dei template del tema non aiutano con il blocco delle risorse. In quel caso, usa uno degli altri metodi descritti in questo articolo.

PrestaShop 1.7 vs 8.x: differenze nell'approccio

PrestaShop 8.x ha perfezionato il sistema di gestione delle risorse introdotto nella 1.7, ma gli approcci fondamentali rimangono gli stessi. Le differenze principali riguardano l'implementazione interna e alcune funzionalità aggiuntive.

In PrestaShop 1.7, il sistema di gestione delle risorse utilizza registerStylesheet e registerJavascript con un sistema di priorità. I metodi Media::unregisterStylesheet e Media::unregisterJavascript funzionano in modo affidabile per le risorse registrate attraverso questo sistema. Tuttavia, i moduli che utilizzano ancora i vecchi metodi addCSS e addJS (che sono deprecati ma ancora funzionanti) non passano attraverso il nuovo sistema di gestione delle risorse, rendendoli più difficili da rimuovere in modo pulito.

PrestaShop 8.x ha migliorato la retrocompatibilità in modo che anche le risorse aggiunte attraverso i vecchi metodi vengano elaborate attraverso la nuova pipeline delle risorse. Questo significa che i metodi Media::unregister funzionano in modo più coerente su tutti i moduli, indipendentemente dal metodo di registrazione utilizzato. Se utilizzi PrestaShop 8.x, l'approccio di deregistrazione è il metodo più affidabile per tutti i moduli.

PrestaShop 8.x ha anche introdotto un migliore cache-busting per le risorse, il che significa che quando rimuovi o modifichi le risorse, le modifiche hanno effetto immediatamente dopo aver svuotato la cache, senza che i clienti vedano versioni memorizzate in cache obsolete. In PrestaShop 1.7, a volte era necessario svuotare sia la cache di PrestaShop sia la cache del browser, o attendere che il sistema Combine, Compress, Cache (CCC) rigenerasse i file combinati.

Entrambe le versioni supportano l'approccio theme.yml per la rimozione delle risorse, e la sintassi è identica. Se stai scrivendo un modulo personalizzato per la gestione delle risorse, lo stesso codice funziona sia su 1.7 che su 8.x con differenze minime.

Misurare i miglioramenti delle prestazioni dopo la disabilitazione delle risorse

Dopo aver disabilitato le risorse dei moduli, dovresti misurare il miglioramento delle prestazioni per confermare che le tue modifiche hanno avuto l'effetto previsto. Usa una combinazione di strumenti per una misurazione completa.

Inizia con la scheda Network dei Chrome DevTools. Confronta il numero totale di richieste e la dimensione totale trasferita prima e dopo le tue modifiche. Filtra per CSS e JS per vedere la riduzione specifica nel numero e nelle dimensioni dei file di fogli di stile e JavaScript. Un'ottimizzazione significativa dovrebbe mostrare una chiara riduzione sia nel numero di richieste sia nella dimensione totale.

Esegui un audit delle prestazioni con Lighthouse prima e dopo. Concentrati sulle metriche più influenzate dal caricamento di CSS e JavaScript: il First Contentful Paint è influenzato dai CSS render-blocking, il Largest Contentful Paint è influenzato dal caricamento complessivo delle risorse e il Total Blocking Time è influenzato dal parsing e dall'esecuzione del JavaScript. Registra queste metriche da almeno tre esecuzioni e confronta le medie.

Usa la scheda Coverage nei Chrome DevTools per misurare l'utilizzo di CSS e JavaScript. Apri la scheda Coverage dal menu a tre punti sotto Altri Strumenti, poi ricarica la pagina. La scheda Coverage ti mostra quanto di ogni file CSS e JavaScript viene effettivamente utilizzato sulla pagina corrente. I file con alte percentuali di inutilizzo (mostrate in rosso) sono candidati per la rimozione o il caricamento condizionale. Dopo aver disabilitato le risorse dei moduli, i file rimanenti dovrebbero mostrare percentuali di utilizzo più alte, indicando che hai rimosso con successo lo spreco.

Considera anche le metriche reali dalla tua piattaforma di analytics. Se usi Google Analytics o uno strumento simile, confronta i tempi di caricamento delle pagine per una settimana prima e dopo la tua ottimizzazione. I dati reali provenienti dai visitatori effettivi su diversi dispositivi e condizioni di rete ti danno il quadro più accurato del miglioramento delle prestazioni.

Rischi e problemi di compatibilità

La disabilitazione delle risorse dei moduli comporta rischi che devi comprendere e gestire. Il rischio più comune è la rottura visiva. Quando rimuovi il CSS di un modulo, i suoi elementi HTML perdono il loro stile e possono essere visualizzati in modo errato. Questo può variare da problemi estetici minori come colori o spaziature errate a problemi di layout importanti come elementi sovrapposti o contenuti invisibili.

La rimozione del JavaScript comporta un rischio maggiore. I moduli moderni spesso dipendono dal loro JavaScript per le funzionalità principali. Rimuovere il JavaScript può causare l'interruzione completa delle funzionalità: pulsanti che non rispondono ai clic, form che non si inviano, popup che non si aprono, contenuti AJAX che non si caricano. Testa sempre ogni funzionalità di un modulo dopo aver rimosso il suo JavaScript.

C'è anche un rischio di compatibilità con gli aggiornamenti dei moduli. Quando un modulo viene aggiornato, lo sviluppatore potrebbe aggiungere nuovi file CSS o JavaScript con ID risorsa diversi. Le tue regole di rimozione, sia in theme.yml che in un modulo personalizzato, potrebbero non intercettare le nuove risorse perché puntano ai vecchi ID. Dopo ogni aggiornamento del modulo, verifica che il tuo blocco delle risorse funzioni ancora correttamente e aggiorna le tue regole se necessario.

Alcuni moduli eseguono il rilevamento delle funzionalità nel loro JavaScript e si comportano diversamente quando il loro CSS non è caricato. Un modulo potrebbe verificare l'esistenza di specifiche classi CSS o stili calcolati prima di inizializzare la sua funzionalità JavaScript. Rimuovere il CSS in questo caso non cambia solo l'aspetto ma rompe anche il comportamento JavaScript che dipende da quegli stati definiti via CSS.

Infine, fai attenzione alle dipendenze tra moduli. Il Modulo A potrebbe caricare una libreria JavaScript come un plugin lightbox che anche il Modulo B utilizza ma non carica autonomamente perché presuppone che sia il Modulo A a fornirla. Rimuovere i file JavaScript del Modulo A in questo scenario romperebbe entrambi i moduli. Controlla le dipendenze condivise prima di rimuovere qualsiasi risorsa.

Un flusso di lavoro pratico per la rimozione sicura delle risorse

Segui questo flusso di lavoro per disabilitare in sicurezza le risorse dei moduli senza rompere il tuo negozio. Per prima cosa, documenta il tuo stato attuale. Fai screenshot di ogni tipo di pagina dove il modulo visualizza contenuti. Registra i punteggi Lighthouse e le statistiche della scheda Network. Questo ti dà una base di confronto e un riferimento per come il modulo dovrebbe apparire e funzionare.

Secondo, identifica le risorse specifiche che vuoi rimuovere. Usa i DevTools per trovare i nomi esatti dei file e gli ID delle risorse. Determina quali pagine necessitano delle risorse e quali no.

Terzo, implementa la rimozione utilizzando il metodo più appropriato di questo articolo. Per una rimozione globale semplice, usa theme.yml. Per una rimozione condizionale basata sul tipo di pagina, crea un modulo personalizzato con chiamate Media::unregister. Per una sostituzione completa delle risorse, sgancia il modulo e fornisci i tuoi stili.

Quarto, testa approfonditamente. Controlla ogni tipo di pagina dove il modulo dovrebbe visualizzare contenuti. Verifica che l'aspetto visivo del modulo sia corretto e che tutte le funzionalità interattive funzionino. Controlla le pagine dove hai rimosso le risorse per confermare che non si stanno più caricando. Testa su più browser e dispositivi.

Quinto, misura il miglioramento delle prestazioni. Esegui audit Lighthouse e confronta con la tua base di riferimento. Controlla la scheda Network per la riduzione nel numero di richieste e nelle dimensioni. Se il miglioramento è significativo, la tua ottimizzazione ha avuto successo. Se il miglioramento è minimo, le risorse che hai rimosso potrebbero non essere state il principale collo di bottiglia delle prestazioni e dovresti indagare altre opportunità di ottimizzazione.

Sesto, documenta le tue modifiche. Registra quali risorse hai rimosso, quale metodo hai utilizzato e quali pagine sono interessate. Questa documentazione è essenziale per la risoluzione dei problemi futuri, specialmente dopo gli aggiornamenti dei moduli, e per il trasferimento di conoscenze se qualcun altro gestisce il negozio.

Seguendo questo approccio sistematico, puoi ridurre in sicurezza il peso delle pagine del tuo negozio e migliorare i tempi di caricamento senza sacrificare le funzionalità dei moduli da cui il tuo negozio dipende. La chiave è sempre testare e misurare: non dare mai per scontato che rimuovere una risorsa sia sicuro e verifica sempre i risultati con dati concreti.

Leggi la risposta completa

Comprendere memory_limit di PHP

La direttiva memory_limit di PHP controlla quanta RAM un singolo processo PHP può consumare prima che il motore lo termini con un errore fatale. Quando vedi il messaggio "Allowed memory size of X bytes exhausted" in PrestaShop, significa che una specifica richiesta PHP ha tentato di utilizzare più memoria di quanto il limite configurato consenta.

Ogni caricamento di pagina in PrestaShop esegue codice PHP che carica il framework, si connette al database, elabora i dati, renderizza i template e invia l'HTML al browser. Ognuno di questi passaggi consuma memoria. Il memory_limit agisce come una rete di sicurezza: impedisce a un singolo processo fuori controllo di consumare tutta la RAM disponibile del server, il che causerebbe il crash di altri processi e potenzialmente l'intera infrastruttura.

Il memory_limit predefinito in PHP è tipicamente 128M (128 megabyte). PrestaShop raccomanda ufficialmente almeno 256M, e molti negozi richiedono 512M o più a seconda della dimensione del catalogo, dei moduli installati e del traffico. Comprendere cosa guida il consumo di memoria ti aiuta a determinare il valore giusto per il tuo negozio piuttosto che aumentare il limite alla cieca.

Come Verificare il Tuo Memory Limit Attuale

Esistono diversi modi per verificare quale memory limit sta attualmente utilizzando la tua installazione PrestaShop.

Dal Back Office di PrestaShop

Naviga in Parametri Avanzati > Informazioni. Questa pagina mostra la configurazione PHP del tuo server, incluso il valore corrente di memory_limit. PrestaShop mostrerà anche avvisi se il valore è inferiore al minimo raccomandato.

Usando phpinfo()

Crea un file temporaneo chiamato info.php nella directory principale di PrestaShop con questo contenuto:

<?php phpinfo(); ?>

Accedici tramite il browser all'indirizzo tuodominio.com/info.php. Cerca nella pagina "memory_limit" per vedere sia il Valore Locale (quello effettivamente attivo) sia il Valore Master (quello impostato in php.ini). Il valore locale può differire dal valore master se un .htaccess, .user.ini o l'applicazione stessa lo sovrascrive.

Importante: Elimina questo file immediatamente dopo il controllo. Una pagina phpinfo() espone la configurazione dettagliata del server che gli attaccanti possono sfruttare.

Via Riga di Comando

Se hai accesso SSH, esegui:

php -i | grep memory_limit

Nota che la configurazione PHP da CLI potrebbe differire dalla configurazione del server web. Per controllare il valore web-facing, usa il metodo phpinfo() o il back office di PrestaShop.

Cause Comuni degli Errori di Memory Limit

Importazioni di Prodotti Massive

L'importazione di prodotti tramite CSV è una delle operazioni più intensive in termini di memoria in PrestaShop. Ogni riga nel file di importazione viene caricata in memoria, elaborata, validata e inserita nel database. Un file CSV con 10.000 prodotti, ognuno con multiple combinazioni, immagini e descrizioni, può facilmente richiedere 512MB o più di memoria.

Lo strumento di importazione di PrestaShop elabora i prodotti in batch, ma la dimensione del batch e la quantità di dati per prodotto determinano il footprint di memoria totale. Campi di testo grandi (descrizioni con HTML), molte colonne e file codificati in UTF-8 con caratteri speciali aumentano tutti l'utilizzo di memoria per riga.

Per ridurre il consumo di memoria durante le importazioni:

Dividi i file CSV grandi in parti più piccole (1.000-2.000 righe ciascuna)
Importa prima i prodotti senza immagini, poi importa le immagini separatamente
Disabilita i moduli non essenziali durante l'importazione (statistiche, indicizzazione ricerca)
Usa l'importazione da riga di comando se disponibile, che evita i limiti di timeout del server web

Prodotti con Molte Combinazioni

I prodotti con molti attributi (taglia, colore, materiale) generano combinazioni in modo esponenziale. Un prodotto con 5 taglie, 10 colori e 3 materiali crea 150 combinazioni. Ogni combinazione è un record separato nel database con il proprio prezzo, riferimento, stock e associazioni di immagini. Quando PrestaShop carica una pagina prodotto per la modifica nel back office, carica tutte le combinazioni in memoria contemporaneamente.

I prodotti con 500+ combinazioni sono un punto critico noto. Con 1.000+ combinazioni, raggiungerai quasi certamente i limiti di memoria con la configurazione predefinita. Le soluzioni includono:

Aumentare memory_limit a 512M o 1G per il back office
Ristrutturare i prodotti per ridurre il numero di combinazioni (prodotti separati invece di mega-combinazioni)
Utilizzare moduli che gestiscono le combinazioni in modo più efficiente tramite paginazione

Moduli Sovraccaricati o Mal Codificati

I moduli di terze parti sono una fonte frequente di problemi di memoria. I problemi comuni includono:

Caricamento di intere tabelle del database in array PHP: Un modulo che esegue SELECT * FROM ps_orders senza una clausola LIMIT carica in memoria ogni ordine mai effettuato. Per un negozio con 100.000 ordini, questo può consumare centinaia di megabyte.
Perdite di memoria nei cicli: Moduli che elaborano elementi in un ciclo ma accumulano oggetti senza liberarli. Il garbage collector di PHP gestisce i casi semplici, ma i riferimenti circolari e i riferimenti memorizzati possono impedire la pulizia.
Logging eccessivo: Logging di debug che scrive array o oggetti di grandi dimensioni nei file di log, usando var_export() o print_r() su oggetti PrestaShop complessi, può consumare enormi quantità di memoria.
Elaborazione immagini non ottimizzata: Moduli che ridimensionano o applicano watermark alle immagini usando GD o ImageMagick caricano l'intera immagine non compressa in memoria. Un'immagine 5000x5000 pixel a 24 bit di profondità colore richiede approssimativamente 75MB di RAM solo per i dati dei pixel.

Per identificare quale modulo sta causando problemi di memoria, controlla attentamente il messaggio di errore. Di solito include un percorso file che punta al modulo responsabile. Puoi anche abilitare la modalità debug di PrestaShop per ottenere stack trace più dettagliati.

Cataloghi Grandi e Query Complesse

I negozi con decine di migliaia di prodotti, molte categorie e strutture di attributi complesse esercitano più pressione sulla memoria durante il normale funzionamento. Le pagine di categoria con la navigazione a strati (ricerca a facette) sono particolarmente impegnative perché il motore dei filtri deve calcolare i valori degli attributi disponibili su migliaia di prodotti.

L'elenco prodotti del back office, l'elenco ordini e l'elenco clienti caricano tutti dati in memoria per la visualizzazione. Con dataset molto grandi, anche la vista elenco di base può raggiungere i limiti di memoria, specialmente quando i moduli aggiungono colonne o calcoli extra a questi elenchi.

Compilazione dei Template Smarty

PrestaShop utilizza il motore di template Smarty, che compila i template in file PHP per un rendering più veloce. Il processo di compilazione stesso consuma memoria, e i template complessi con molti include, cicli e blocchi condizionali richiedono più memoria per la compilazione. Dopo la prima compilazione vengono utilizzate le versioni in cache, quindi questo è principalmente un problema quando la cache viene svuotata o durante lo sviluppo.

Come Aumentare il Memory Limit

Metodo 1: php.ini

Il metodo più affidabile è modificare direttamente il file di configurazione PHP. La posizione dipende dalla tua configurazione:

Debian/Ubuntu: /etc/php/8.x/fpm/php.ini (PHP-FPM) o /etc/php/8.x/apache2/php.ini (mod_php)
CentOS/RHEL: /etc/php.ini o /etc/php.d/
cPanel: MultiPHP INI Editor in WHM o cPanel

Trova la riga memory_limit e modificala:

memory_limit = 512M

Dopo il salvataggio, riavvia PHP-FPM o Apache:

# PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache con mod_php
sudo systemctl restart apache2

Metodo 2: .htaccess (Solo Apache con mod_php)

Aggiungi questa riga al file .htaccess nella directory principale di PrestaShop:

php_value memory_limit 512M

Questo metodo funziona solo con Apache che esegue mod_php. Se usi PHP-FPM (che è più comune nelle configurazioni moderne), questa direttiva viene silenziosamente ignorata o può causare un errore 500. Per verificare quale handler PHP stai usando, guarda la riga Server API nell'output di phpinfo().

Metodo 3: .user.ini (PHP-FPM)

Crea o modifica un file chiamato .user.ini nella directory principale di PrestaShop:

memory_limit = 512M

PHP-FPM legge i file .user.ini dalla document root. Nota che le modifiche hanno effetto dopo il periodo user_ini.cache_ttl (predefinito 300 secondi / 5 minuti), quindi potresti dover attendere o riavviare PHP-FPM affinché la modifica abbia effetto immediatamente.

Metodo 4: All'Interno del Codice di PrestaShop

PrestaShop imposta il proprio memory limit nel file config/defines.inc.php. Cerca una riga come:

@ini_set('memory_limit', '256M');

Puoi aumentare questo valore direttamente nel codice. Tuttavia, questo approccio ha una limitazione: la funzione ini_set() può solo aumentare il memory limit fino al valore impostato in php.ini. Se php.ini imposta memory_limit = 128M e il tuo codice tenta di impostarlo a 512M, il limite effettivo rimarrà 128M (a meno che il valore master non consenta le sovrascritture, il che dipende dalla classificazione PHP_INI_ALL vs PHP_INI_SYSTEM).

Metodo 5: Configurazione Per-Pool (PHP-FPM)

Se gestisci il tuo server, puoi impostare i limiti di memoria per pool PHP-FPM. Modifica il file di configurazione del pool (es. /etc/php/8.2/fpm/pool.d/www.conf) e aggiungi:

php_admin_value[memory_limit] = 512M

Usando php_admin_value questa impostazione diventa immutabile — non può essere sovrascritta da .user.ini o ini_set(). Questo è utile per applicare limiti in ambienti multi-tenant.

Memoria Per-Processo vs Memoria Condivisa

È importante capire che memory_limit si applica a ogni singolo processo PHP, non a PHP nel suo complesso. Se imposti memory_limit = 512M e il tuo server esegue 20 processi PHP concorrenti, il consumo massimo teorico di memoria da parte di PHP è 10GB (20 x 512MB).

Ecco perché aumentare ciecamente il memory limit può causare problemi. Su un server con 4GB di RAM, impostare memory_limit = 1G con 10 worker PHP-FPM significa che PHP da solo potrebbe tentare di usare 10GB, causando un pesante swapping del sistema o attivando il Linux OOM killer, che termina forzatamente i processi per liberare memoria.

L'approccio corretto è bilanciare il memory limit con il numero di worker PHP:

RAM disponibile per PHP = RAM totale - overhead SO - memoria MySQL - memoria server web - altri servizi
Worker PHP massimi = RAM disponibile per PHP / memory_limit

Ad esempio, su un VPS da 4GB: 4GB totali - 0,5GB SO - 1GB MySQL - 0,25GB Nginx = 2,25GB per PHP. Con memory_limit = 256M, puoi eseguire in sicurezza 8-9 worker PHP-FPM. Con memory_limit = 512M, puoi eseguire solo 4 worker, il che significa che meno richieste concorrenti possono essere servite.

Configura il pool PHP-FPM di conseguenza:

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Diagnosticare Perdite di Memoria e Uso Eccessivo

Se aumentare il memory limit ritarda solo l'errore anziché risolverlo, probabilmente hai una perdita di memoria o un processo inefficiente. Ecco come diagnosticare la causa principale.

Abilita la Modalità Debug di PrestaShop

Modifica config/defines.inc.php e imposta:

define('_PS_MODE_DEV_', true);

Questo abilita la segnalazione dettagliata degli errori, incluso il file esatto e il numero di riga in cui il memory limit è stato superato. Lo stack trace mostra la catena di chiamate di funzione che ha portato all'errore, aiutandoti a identificare il modulo o la funzione core responsabile.

Monitora l'Uso della Memoria nel Codice

Puoi aggiungere il monitoraggio della memoria a sezioni specifiche del codice per individuare dove si verificano i picchi di memoria:

error_log('Memoria prima dell\'operazione: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
// ... operazione ...
error_log('Memoria dopo l\'operazione: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
error_log('Picco di memoria: ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB');

La funzione memory_get_usage(true) restituisce la quantità effettiva di memoria allocata dal SO a PHP, mentre memory_get_peak_usage(true) restituisce la quantità massima allocata in qualsiasi punto durante la richiesta.

Usa il Profiling di Xdebug

Il profiler di Xdebug genera report dettagliati delle chiamate di funzione, del tempo di esecuzione e del consumo di memoria. Abilitalo temporaneamente nella configurazione PHP:

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Apri i file cachegrind generati in uno strumento come KCacheGrind o Webgrind per visualizzare quali funzioni consumano più memoria. Questo è l'approccio diagnostico più approfondito ma dovrebbe essere utilizzato solo su server di sviluppo a causa del significativo overhead sulle prestazioni.

Controlla le Query Lente e MySQL

A volte quello che sembra essere un problema di memoria PHP è in realtà un problema MySQL. Una query lenta che restituisce milioni di righe causerà l'allocazione di memoria PHP per l'intero set di risultati. Controlla il log delle query lente di MySQL:

sudo tail -100 /var/log/mysql/slow-query.log

Se vedi query con set di risultati grandi, aggiungi clausole LIMIT appropriate o implementa la paginazione nel modulo responsabile.

Memoria OPcache

OPcache è un'estensione PHP che memorizza nella cache il bytecode PHP compilato in memoria condivisa, eliminando la necessità di analizzare e compilare i file PHP ad ogni richiesta. OPcache ha la propria allocazione di memoria, separata da memory_limit.

La memoria OPcache predefinita (opcache.memory_consumption) è 128MB. PrestaShop con diversi moduli installati può facilmente superare questo valore. Quando OPcache esaurisce la memoria, inizia a espellere le voci in cache e ricompilare i file ad ogni richiesta, causando un significativo degrado delle prestazioni.

Controlla lo stato di OPcache dalla riga di comando:

php -r "print_r(opcache_get_status());"

Oppure guarda la sezione opcache nell'output di phpinfo(). Valori chiave da monitorare:

opcache.memory_consumption: Memoria totale allocata per OPcache (aumenta a 256M per PrestaShop)
opcache.max_accelerated_files: Numero massimo di file che OPcache può memorizzare in cache (aumenta a 20000 per PrestaShop)
Memoria usata vs Memoria libera: Se la memoria libera è vicina allo zero, aumenta memory_consumption
Cache hit rate: Dovrebbe essere superiore al 99%. Sotto il 95% indica pressione sulla memoria o invalidazione frequente della cache

Configurazione OPcache raccomandata per PrestaShop:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

Nota che la memoria OPcache è condivisa tra tutti i processi PHP, a differenza di memory_limit che è per singolo processo. Aumentare la memoria OPcache non si moltiplica per il numero di worker.

Configurazione Memoria MySQL

MySQL ha la propria configurazione di memoria che influenza indirettamente le prestazioni di PrestaShop e può contribuire alla pressione complessiva sulla memoria del server. Le principali impostazioni di memoria MySQL includono:

innodb_buffer_pool_size: Il buffer di memoria principale per le tabelle InnoDB. Imposta al 50-70% della RAM disponibile su un server database dedicato, o al 25-50% su un server condiviso che esegue sia PHP che MySQL. Questa è la singola impostazione di prestazioni MySQL più importante.
sort_buffer_size e join_buffer_size: Buffer per connessione per ordinamento e join. Mantienili ai valori predefiniti a meno che tu non abbia query lente specifiche che beneficerebbero di buffer più grandi. Impostarli troppo alti spreca memoria perché vengono allocati per connessione.
query_cache_size: Deprecato in MySQL 8.0 e rimosso completamente. Se sei ancora su MySQL 5.7, una piccola cache query (64M) può aiutare, ma cache grandi causano contesa e riducono le prestazioni.

Se MySQL consuma troppa memoria, ne rimane meno per PHP, potenzialmente costringendoti a ridurre i worker PHP-FPM o il memory limit. Usa mysqladmin status o SHOW GLOBAL STATUS per monitorare il consumo di memoria di MySQL.

Quando Aggiornare il Tuo Hosting

A volte aumentare il memory limit e ottimizzare il codice non è sufficiente. Ecco i segnali che indicano la necessità di un server più potente:

Stai costantemente raggiungendo il memory limit massimo: Se i tuoi processi utilizzano regolarmente il 90%+ della memoria allocata, anche dopo l'ottimizzazione, hai bisogno di più RAM.
Il server fa swap frequentemente: Controlla con free -h o vmstat 1. Se l'utilizzo dello swap è costantemente alto, non hai abbastanza RAM fisica.
Ridurre i worker PHP sta penalizzando le prestazioni: Se hai dovuto ridurre i worker PHP-FPM a 3-4 per accomodare il memory limit, il tuo sito non può gestire efficacemente i visitatori concorrenti.
Il tuo catalogo continua a crescere: Un negozio che funzionava bene con 1.000 prodotti potrebbe avere difficoltà con 10.000. Le esigenze di memoria scalano con la dimensione del catalogo, specialmente per l'indicizzazione della ricerca, l'elenco delle categorie e le operazioni del back office.
Hai bisogno di memory_limit superiore a 1G: Se un singolo processo PHP necessita di più di 1GB di memoria per operazioni normali (non importazioni), qualcosa è fondamentalmente sbagliato nel tuo codice o nella capacità del tuo hosting. Investiga la causa principale prima di continuare ad aumentare il limite.

Quando aggiorni, dai priorità a più RAM rispetto a più core CPU per PrestaShop. Un server con 8GB di RAM e 2 core servirà PrestaShop meglio di uno con 4GB di RAM e 4 core. Considera anche la separazione di MySQL su un proprio server o l'uso di un servizio di database gestito, che libera completamente la RAM del server applicativo per PHP.

Riferimento Rapido: Impostazioni Raccomandate per Dimensione del Negozio

Le seguenti raccomandazioni servono come punti di partenza. Monitora il tuo utilizzo effettivo e regolati di conseguenza.

Negozio piccolo (meno di 1.000 prodotti, pochi moduli): memory_limit = 256M, 2GB RAM, 4-6 worker PHP
Negozio medio (1.000-10.000 prodotti, 20+ moduli): memory_limit = 512M, 4GB RAM, 6-8 worker PHP
Negozio grande (10.000+ prodotti, molte combinazioni): memory_limit = 512M-1G, 8GB+ RAM, 8-16 worker PHP, server database separato
Durante le importazioni: Aumenta temporaneamente a 1G o 2G, poi ripristina il valore normale

Ricorda che il memory limit è un tetto di sicurezza, non un obiettivo. Un negozio PrestaShop ben ottimizzato dovrebbe raramente utilizzare più di 128-256MB per richiesta durante i normali caricamenti di pagina. Se le operazioni normali necessitano costantemente di 512MB o più, investiga e correggi la causa sottostante piuttosto che continuare ad aumentare il limite.

Leggi la risposta completa

Comprendere max_input_vars in PrestaShop

Se hai mai provato a salvare un prodotto con decine o centinaia di combinazioni in PrestaShop e hai riscontrato un salvataggio silenzioso fallito, un salvataggio parziale o un errore criptico, il colpevole è quasi certamente la direttiva PHP max_input_vars. Questa impostazione controlla quanti campi di form individuali PHP accetterà in una singola richiesta POST. Quando PrestaShop invia un form prodotto che supera questo limite, ogni campo oltre la soglia viene silenziosamente scartato, portando a salvataggi incompleti, combinazioni mancanti o dati che semplicemente scompaiono senza alcun messaggio di errore visibile.

Per impostazione predefinita, la maggior parte delle installazioni PHP viene fornita con max_input_vars impostato a 1000. Per un semplice blog o sito vetrina, questo è più che sufficiente. Per PrestaShop, tuttavia, le pagine di modifica dei prodotti possono generare migliaia di campi di form, specialmente quando sono coinvolte combinazioni, campi multilingua e caratteristiche personalizzate. Comprendere questa direttiva, sapere come calcolare il valore di cui il tuo negozio ha effettivamente bisogno e applicare la correzione correttamente ti farà risparmiare ore di debugging.

Perché PrestaShop Necessita di Valori max_input_vars Elevati

Il form di modifica prodotto di PrestaShop è uno dei form più complessi in qualsiasi piattaforma e-commerce. Ogni combinazione di un prodotto genera molteplici campi di input: uno per l'impatto sul prezzo, uno per l'impatto sul peso, uno per la quantità, uno per il riferimento, uno per l'EAN-13, uno per l'UPC, uno per l'MPN, uno per la quantità minima, uno per la soglia di stock basso, uno per la data di disponibilità e diversi altri a seconda della configurazione. Una singola combinazione può facilmente produrre da 15 a 25 campi di form.

Ora moltiplica questo per il numero di combinazioni. Una maglietta disponibile in 5 taglie e 10 colori ha 50 combinazioni. A 20 campi per combinazione, sono già 1.000 campi solo per la scheda combinazioni. Aggiungi i campi del prodotto base, i campi SEO per ogni lingua, i valori delle caratteristiche, i prezzi specifici e le altre schede, e puoi facilmente raggiungere 1.500-2.000 campi per un prodotto moderatamente complesso.

Per i negozi che vendono prodotti con set di attributi estesi, come elettronica con diverse capacità di archiviazione, colori, opzioni di RAM e varianti regionali, un singolo prodotto può avere 200 o più combinazioni, generando 4.000+ campi di form. Il limite predefinito di 1.000 non è nemmeno lontanamente sufficiente.

Sintomi di max_input_vars Troppo Basso

L'aspetto più frustrante del raggiungimento del limite max_input_vars è che PHP non genera un errore. Tronca silenziosamente i dati di input. Questo significa che vedrai una varietà di sintomi confusi senza alcuna indicazione chiara di cosa sia andato storto.

Il sintomo più comune è che le combinazioni scompaiono dopo il salvataggio. Crei 80 combinazioni, clicchi salva e quando la pagina si ricarica ne sono presenti solo 40. Il form ha inviato tutte le 80, ma PHP ha elaborato solo la prima porzione dei dati POST prima di raggiungere il limite, quindi le combinazioni rimanenti non sono mai state ricevute dal server.

Un altro sintomo comune è che i dati del prodotto si salvano parzialmente. La scheda informazioni di base si salva correttamente, ma i dati di prezzo, SEO o combinazioni vengono persi. Questo succede perché i campi del form vengono inviati in un ordine specifico, e qualsiasi campo che viene dopo il punto di taglio viene scartato.

Potresti anche sperimentare la pagina del prodotto che si ricarica semplicemente senza salvare, o PrestaShop che mostra un errore generico come "Si è verificato un errore durante l'aggiornamento del prodotto". In PrestaShop 1.7 e 8.x, la pagina prodotto basata su Symfony potrebbe mostrare errori di validazione per campi obbligatori che erano effettivamente compilati ma troncati da PHP.

Un sintomo meno ovvio riguarda i negozi multilingua. Se il tuo negozio supporta 5 lingue, ogni campo di testo viene moltiplicato per 5. Un prodotto che si salva correttamente in un negozio monolingua fallisce in uno multilingua perché i campi aggiuntivi delle lingue spingono il totale oltre il limite.

Come Verificare il Valore Attuale di max_input_vars

Prima di apportare modifiche, verifica la tua impostazione attuale. Crea un file PHP nella directory principale di PrestaShop (ricorda di eliminarlo dopo per sicurezza):

<?php phpinfo(); ?>

Accedi a questo file tramite il browser e cerca max_input_vars. Vedrai sia il Valore Locale (quello attualmente attivo) sia il Valore Master (il predefinito da php.ini). Presta attenzione al Valore Locale, poiché potrebbe differire dal Valore Master se un .htaccess o una configurazione per directory lo sovrascrive.

In alternativa, puoi verificare dal back office di PrestaShop. Naviga in Parametri Avanzati, poi Informazioni. La sezione configurazione PHP mostra le impostazioni PHP chiave incluso max_input_vars. PrestaShop 1.7.7 e versioni successive mostrano anche un avviso in questa pagina se il valore è considerato troppo basso.

Calcolare il Valore max_input_vars di Cui Hai Bisogno

Piuttosto che impostare ciecamente un numero alto, puoi stimare il valore che il tuo negozio richiede. Usa questa formula come base di partenza:

Valore richiesto = (numero di combinazioni x campi per combinazione) + campi prodotto base + (campi di testo x numero di lingue) + margine di sicurezza

Per un esempio pratico, considera un negozio con 3 lingue e un prodotto con 100 combinazioni. Il calcolo sarebbe: 100 combinazioni moltiplicate per 20 campi ciascuna equivalgono a 2.000. I campi prodotto base su tutte le schede contribuiscono con circa 200. I campi di testo (nome, descrizione, meta title, meta description, link rewrite e altri) moltiplicati per 3 lingue aggiungono altri 150. Aggiungendo un margine di sicurezza del 20% si arriva a un totale di circa 2.820.

Per la maggior parte dei negozi PrestaShop, impostare max_input_vars a 10000 fornisce ampio margine. I negozi con prodotti che hanno 300+ combinazioni o che operano in 5+ lingue dovrebbero considerare 20000 o anche 50000. L'overhead di memoria di un valore più alto è trascurabile sui server moderni.

Come Aumentare max_input_vars

Metodo 1: php.ini (Raccomandato)

Se hai accesso alla configurazione PHP del tuo server, modificare php.ini è l'approccio più pulito. Individua il tuo file php.ini (l'output di phpinfo() ti dice esattamente quale file viene caricato) e trova o aggiungi la seguente riga:

max_input_vars = 10000

Dopo aver salvato il file, riavvia il server web o il servizio PHP-FPM affinché la modifica abbia effetto. Su Apache con mod_php, riavvia Apache. Su Nginx con PHP-FPM, riavvia il servizio php-fpm. Il comando esatto dipende dal tuo sistema operativo e dalla versione PHP.

Metodo 2: .htaccess (Apache con mod_php o mod_fcgid)

Se non hai accesso a php.ini, come su hosting condiviso, puoi provare ad aggiungere la direttiva al file .htaccess nella directory principale di PrestaShop:

php_value max_input_vars 10000

Questo metodo funziona solo se PHP viene eseguito come modulo Apache (mod_php). Se il tuo hosting usa PHP-FPM o CGI, questa direttiva causerà un errore 500 Internal Server Error. In tal caso, rimuovi la riga immediatamente e prova il metodo successivo.

Metodo 3: .user.ini (PHP-FPM / CGI)

Per i server che eseguono PHP-FPM, crea o modifica un file .user.ini nella directory principale di PrestaShop:

max_input_vars = 10000

Nota che le modifiche a .user.ini non sono immediate. PHP memorizza nella cache questo file per un periodo definito da user_ini.cache_ttl, che è predefinito a 300 secondi (5 minuti). Attendi almeno 5 minuti dopo aver salvato il file prima di testare.

Metodo 4: Pannello di Controllo dell'Hosting

Molti provider di hosting espongono le impostazioni PHP attraverso il loro pannello di controllo. In cPanel, naviga in "Select PHP Version" o "MultiPHP INI Editor" e cerca max_input_vars. In Plesk, vai nelle Impostazioni PHP per il tuo dominio. DirectAdmin e altri pannelli hanno opzioni simili. Questo è spesso il metodo più semplice su hosting condiviso.

La Complicazione della Patch Suhosin

Suhosin è una patch di sicurezza PHP che era comune sui server più vecchi, in particolare quelli con PHP 5.x. Impone il proprio set di limiti di input che sovrascrivono l'impostazione standard max_input_vars. Anche se aumenti max_input_vars a 10000, Suhosin potrebbe ancora imporre un limite inferiore attraverso le proprie direttive.

Le impostazioni specifiche di Suhosin che devi regolare sono:

suhosin.post.max_vars = 10000
suhosin.request.max_vars = 10000

Queste devono essere impostate in aggiunta al max_input_vars standard. Se l'output di phpinfo() mostra una sezione Suhosin, sei interessato e devi regolare tutti e tre i valori. Le impostazioni Suhosin tipicamente possono essere cambiate solo in php.ini, non in .htaccess o .user.ini.

Sulle installazioni PHP 7.x e 8.x moderne, Suhosin è raramente presente. Se stai eseguendo una versione PHP recente, quasi certamente non devi preoccupartene. Tuttavia, se sei su un account di hosting condiviso più vecchio che non è stato aggiornato, vale la pena verificare.

Approcci Alternativi per Prodotti con 500+ Combinazioni

Mentre aumentare max_input_vars risolve il problema immediato, i negozi con numeri estremamente elevati di combinazioni per prodotto dovrebbero considerare approcci alternativi che riducono il conteggio dei campi del form o evitano completamente la limitazione.

Importare le Combinazioni tramite CSV

La funzionalità di importazione integrata di PrestaShop elabora le combinazioni attraverso l'upload di file anziché l'invio del form, bypassando completamente il limite max_input_vars. Prepara un file CSV con i dati delle tue combinazioni e importalo attraverso il back office in Parametri Avanzati, Importa. Questo è spesso l'approccio più pratico per prodotti con centinaia di combinazioni.

Usare l'API Webservice di PrestaShop

L'API webservice di PrestaShop consente di creare e aggiornare le combinazioni in modo programmatico. Le richieste API non sono soggette a max_input_vars perché usano payload strutturati in XML o JSON anziché dati POST codificati come form. Questo approccio richiede conoscenze tecniche ma scala a qualsiasi numero di combinazioni.

Dividere i Prodotti Grandi

In alcuni casi, ha più senso dal punto di vista commerciale dividere un prodotto con 500+ combinazioni in più prodotti. Un prodotto con 5 taglie e 100 colori potrebbe essere diviso in 5 prodotti, uno per taglia, ciascuno con 100 opzioni di colore. Questo non solo evita la limitazione tecnica ma spesso migliora anche l'esperienza del cliente.

Gestire le Combinazioni in Batch

Se devi utilizzare il form del back office, crea le combinazioni in batch più piccoli. Genera 50 combinazioni alla volta, salva, poi genera le successive 50. Questo è noioso ma evita di raggiungere il limite senza richiedere alcuna modifica alla configurazione del server.

Verificare la Correzione

Dopo aver aumentato max_input_vars, verifica che la modifica abbia avuto effetto. Controlla di nuovo phpinfo() e conferma che il Valore Locale corrisponde a quello che hai impostato. Poi testa modificando il tuo prodotto più complesso, apportando una piccola modifica e salvando. Tutte le combinazioni e i dati dovrebbero essere preservati.

Se il problema persiste dopo aver aumentato il valore, verifica queste possibilità aggiuntive. Il tuo provider di hosting potrebbe sovrascrivere le tue impostazioni con una configurazione globale. L'istanza PHP che serve il tuo sito web potrebbe essere diversa da quella mostrata in un phpinfo() da CLI. Potrebbe esserci un limite del server web come LimitRequestBody di Apache o client_max_body_size di Nginx che sta troncando anche la richiesta. Alcuni web application firewall (WAF) o plugin di sicurezza (come ModSecurity) impongono i propri limiti sulla dimensione dei dati POST e sul numero di parametri.

Impostazioni PHP Correlate da Verificare

Mentre regoli max_input_vars, rivedi queste impostazioni correlate che possono causare problemi con form prodotto di grandi dimensioni:

post_max_size: Imposta la dimensione massima dei dati POST in byte. Se i dati del tuo form superano questo limite (tipicamente quando i prodotti hanno molti campi di testo grandi in più lingue), l'intero POST viene scartato. Imposta questo ad almeno 32M per PrestaShop.

memory_limit: L'elaborazione di migliaia di campi di form richiede memoria. Se PHP esaurisce la memoria durante l'analisi dell'input, la richiesta fallisce. Un valore di 256M o 512M è raccomandato per PrestaShop.

max_execution_time: Il salvataggio di un prodotto con molte combinazioni comporta numerose query al database. Se l'operazione di salvataggio richiede più tempo del tempo di esecuzione consentito, verrà terminata a metà processo, portando a salvataggi parziali. Imposta questo ad almeno 300 secondi per negozi con prodotti complessi.

max_input_nesting_level: PrestaShop usa array annidati nei dati del form (ad esempio, i campi multilingua usano array come name[1], name[2]). Il livello di annidamento predefinito di 64 è generalmente sufficiente, ma se incontri problemi con strutture di form profondamente annidate, aumentalo a 128 o 256.

Note Specifiche per Versione di PrestaShop

In PrestaShop 1.6, la pagina prodotto è interamente PHP legacy con un invio di form tradizionale. Il problema max_input_vars riguarda tutte le operazioni sulla pagina prodotto. Non c'è soluzione alternativa se non aumentare il limite o usare le importazioni.

PrestaShop 1.7 ha introdotto una pagina prodotto parzialmente basata su Symfony. Sebbene l'architettura sia cambiata, l'invio del form sottostante usa ancora dati POST ed è ancora soggetto agli stessi limiti PHP. Il componente form di Symfony potrebbe mostrare messaggi di errore più informativi quando mancano dei campi, ma la causa principale è la stessa.

PrestaShop 8.x presenta una pagina prodotto completamente ridisegnata con una nuova struttura form Symfony. La gestione delle combinazioni è stata significativamente rielaborata, con le combinazioni ora gestite attraverso un'interfaccia dedicata che carica e salva i dati tramite AJAX in batch più piccoli. Questa modifica architetturale riduce naturalmente l'impatto di max_input_vars per i dati delle combinazioni, anche se il form principale del prodotto può ancora essere influenzato in negozi multilingua con molte caratteristiche.

PrestaShop 9.x continua la tendenza verso la gestione dei dati basata su AJAX, riducendo ulteriormente la dipendenza da invii di form massivi. Tuttavia, max_input_vars rimane rilevante per le operazioni massive e i moduli legacy che usano ancora invii di form tradizionali.

Prevenire Problemi Futuri

Imposta max_input_vars a un valore generoso durante l'installazione iniziale di PrestaShop piuttosto che aspettare che i problemi si manifestino. Un valore di 20000 è sicuro per praticamente tutti gli scenari e non ha un impatto significativo sulle prestazioni. Documenta l'impostazione nelle tue note di configurazione del server in modo che le future migrazioni la preservino.

Se sei un provider di hosting o un amministratore di sistema che gestisce più installazioni PrestaShop, considera di impostare max_input_vars = 20000 come predefinito nei tuoi template di configurazione PHP. Questa singola modifica elimina una delle richieste di supporto più comuni relative alla gestione dei prodotti PrestaShop.

Monitora i log degli errori dopo aver apportato le modifiche. Sebbene il troncamento max_input_vars in sé non generi errori PHP, alcune versioni di PrestaShop registrano avvisi quando rilevano che i dati ricevuti non corrispondono ai dati attesi. Queste voci di log possono aiutarti a identificare se il limite viene ancora raggiunto nonostante l'aumento.

Leggi la risposta completa

Perché le Pagine Bianche Si Verificano Dopo gli Aggiornamenti di PrestaShop

Una pagina bianca vuota, spesso chiamata White Screen of Death (WSOD), è uno dei problemi più comuni e allarmanti che i proprietari di negozi PrestaShop affrontano dopo l'aggiornamento del software core. Avvii un aggiornamento dalla versione 1.7.8.7 alla 1.7.8.8, o dalla 8.1.0 alla 8.1.5, il processo sembra completarsi, e poi l'intero negozio, sia il front office che il back office, mostra solo uno schermo bianco. Nessun messaggio di errore, nessun contenuto parziale, solo il vuoto.

Comprendere perché questo accade richiede la comprensione di ciò che fa un aggiornamento del core di PrestaShop. Il processo di aggiornamento sostituisce centinaia di file PHP, modifica le tabelle del database, rigenera gli indici delle classi, svuota le cache e potenzialmente esegue query di migrazione. Qualsiasi errore in qualsiasi punto di questa catena può lasciare il negozio in uno stato inconsistente in cui PHP incontra un errore fatale ma non ha modo di visualizzarlo perché la segnalazione degli errori è disabilitata in modalità produzione.

Le cause più comuni rientrano in diverse categorie: moduli incompatibili che fanno riferimento a classi core rimosse o modificate, discrepanze della versione PHP tra la vecchia e la nuova versione di PrestaShop, conflitti dei file di override dove le personalizzazioni si scontrano con i file core modificati, risorse server insufficienti che causano la terminazione del processo di aggiornamento a metà, e fallimenti della migrazione del database che lasciano le tabelle in uno stato inconsistente.

Passo 1: Abilitare la Modalità Debug

La primissima azione quando ti trovi di fronte a una pagina bianca è rendere visibili gli errori. PrestaShop sopprime l'output degli errori in modalità produzione per evitare di esporre informazioni sensibili ai visitatori. Devi abilitare temporaneamente la modalità debug per vedere cosa sta effettivamente andando storto.

Il metodo più veloce è modificare il file /config/defines.inc.php. Cerca la riga che definisce _PS_MODE_DEV_ e cambiala:

define('_PS_MODE_DEV_', true);

Se non puoi accedere ai file via FTP o SSH perché anche il tuo pannello di hosting è inaccessibile, alcuni provider di hosting offrono un file manager attraverso il loro pannello di controllo (cPanel, Plesk, DirectAdmin) che funziona indipendentemente dalla tua installazione PrestaShop.

In PrestaShop 8.x, puoi anche abilitare la modalità debug attraverso il file .env nella directory principale. Cambia APP_ENV=prod in APP_ENV=dev e imposta APP_DEBUG=1. Questo attiva la toolbar di debug Symfony e le pagine di errore dettagliate.

Dopo aver abilitato la modalità debug, ricarica la pagina. Invece di uno schermo bianco, dovresti ora vedere un messaggio di errore dettagliato con un percorso file, un numero di riga e uno stack trace. Questo messaggio di errore è la chiave per diagnosticare e risolvere il problema.

Passo 2: Controllare i Log degli Errori

Se l'abilitazione della modalità debug mostra ancora una pagina bianca (cosa che può accadere se l'errore si verifica prima che PHP carichi il framework di PrestaShop), controlla direttamente i log degli errori del server.

Sui server Apache, il log degli errori si trova tipicamente in /var/log/apache2/error.log o /var/log/httpd/error_log. Su Nginx con PHP-FPM, controlla /var/log/nginx/error.log e /var/log/php-fpm/error.log (o /var/log/php8.1-fpm.log a seconda della tua versione PHP). Su hosting condiviso, i log degli errori sono generalmente accessibili attraverso il pannello di controllo dell'hosting o in una directory logs all'interno del tuo account di hosting.

PrestaShop mantiene anche i propri file di log nella directory /var/logs/ (PrestaShop 1.7) o /var/log/ (PrestaShop 8.x). Cerca file con la data corrente. Questi log basati su Symfony possono contenere informazioni dettagliate su cosa è andato storto durante il processo di aggiornamento.

Inoltre, controlla la directory /log/ nella directory principale di PrestaShop per eventuali file di log degli errori. Alcune versioni di PrestaShop scrivono errori critici qui quando non possono visualizzarli sullo schermo.

Causa Comune 1: Moduli Incompatibili

I moduli sono la causa più frequente di pagine bianche dopo gli aggiornamenti. Un modulo che funzionava perfettamente su PrestaShop 1.7.8.7 può mandare in crash l'intero negozio sulla 1.7.8.8 se utilizza classi o metodi core interni che sono cambiati nell'aggiornamento.

Il messaggio di errore appare tipicamente come: Fatal error: Class 'NomeClasse' not found oppure Fatal error: Call to undefined method NomeClasse::nomeMetodo() oppure Fatal error: Declaration of ClasseModulo::hookMethod() must be compatible with ClasseCore::hookMethod().

Per risolvere, devi identificare e disabilitare il modulo problematico. Se puoi accedere al back office (a volte solo il front office va in crash), vai in Moduli e disabilita i moduli recentemente installati o aggiornati uno alla volta fino a quando il problema si risolve.

Se anche il back office è inaccessibile, disabilita i moduli attraverso il database. Connettiti al database usando phpMyAdmin o un client MySQL ed esegui:

UPDATE ps_module SET active = 0 WHERE name = 'nome_modulo_problematico';

Se non sai quale modulo sta causando il problema, puoi disabilitare tutti i moduli di terze parti contemporaneamente impostando la loro colonna active a 0. Prima identifica quali moduli sono di terze parti controllando la directory /modules/ per i moduli non PrestaShop. Poi disabilitali selettivamente.

Un approccio più aggressivo è rinominare la directory del modulo. Ad esempio, rinomina /modules/qualchemodulo/ in /modules/qualchemodulo_disabilitato/. PrestaShop non può caricare un modulo la cui directory non corrisponde al nome registrato, disabilitandolo efficacemente senza toccare il database.

Causa Comune 2: Incompatibilità della Versione PHP

Ogni versione di PrestaShop richiede un intervallo specifico di versioni PHP. PrestaShop 1.7.6 e precedenti richiedono PHP 7.1 a 7.3. PrestaShop 1.7.7 a 1.7.8 supportano PHP 7.2 a 8.0. PrestaShop 8.0 richiede PHP 7.2 a 8.1. PrestaShop 8.1 richiede PHP 8.0 a 8.2. PrestaShop 9.0 richiede PHP 8.1 o superiore.

Se il tuo ambiente di hosting ha cambiato le versioni PHP durante o contemporaneamente all'aggiornamento di PrestaShop, potresti incontrare errori di sintassi o chiamate a funzioni deprecate. Gli errori comuni di compatibilità PHP includono: Deprecated: Function create_function() is deprecated (PHP 7.2+ con codice scritto per PHP 5.x), Fatal error: Uncaught Error: Call to undefined function mysql_connect() (PHP 7.0+ ha rimosso l'estensione mysql), e Fatal error: Array and string offset access syntax with curly braces is no longer supported (PHP 8.0+).

Controlla la tua versione PHP attuale guardando l'output di phpinfo() o eseguendo php -v dalla riga di comando. Se la versione è fuori dall'intervallo supportato per la tua versione di PrestaShop, passa a una versione PHP compatibile attraverso il pannello di controllo del tuo hosting.

Causa Comune 3: Conflitti degli Override

Il sistema di override di PrestaShop consente a moduli e sviluppatori di modificare il comportamento core posizionando file di classe modificati nella directory /override/. Durante un aggiornamento, le classi core cambiano, ma i file di override rimangono. Se un override fa riferimento a una firma di metodo che è cambiata, una proprietà che è stata rimossa o una classe che è stata rinominata, l'override causa un errore fatale.

Il file di indice delle classi in /var/cache/prod/class_index.php (o /cache/class_index.php nelle versioni precedenti) mappa i nomi delle classi alle loro posizioni di file, inclusi gli override. Un indice delle classi obsoleto o corrotto può caricare il file sbagliato per una classe, causando crash immediati.

Per verificare se gli override sono il problema, disabilita temporaneamente il sistema di override. Modifica /config/defines.inc.php e aggiungi o modifica:

define('_PS_HOST_MODE_', false);

Poi elimina il file di indice delle classi per forzare PrestaShop a rigenerarlo senza override. Se il negozio si carica dopo questa modifica, il problema è in uno dei tuoi file di override.

Per identificare l'override problematico specifico, guarda nelle directory /override/classes/ e /override/controllers/. Rimuovi i file di override uno alla volta, eliminando l'indice delle classi dopo ogni rimozione, fino a trovare quello che causa il crash. Una volta identificato, aggiorna l'override per renderlo compatibile con la nuova versione core o rimuovilo completamente se non è più necessario.

Causa Comune 4: Cache e File Compilati

PrestaShop genera template Smarty compilati, cache del container Symfony, mappe delle classi e vari altri file in cache che diventano non validi dopo un aggiornamento. Se il processo di aggiornamento non ha svuotato correttamente queste cache, il negozio tenta di utilizzare file in cache che fanno riferimento alla vecchia struttura del codice.

Svuota tutte le cache manualmente eliminando il contenuto di queste directory (elimina il contenuto, non le directory stesse):

/var/cache/prod/ e /var/cache/dev/ per la cache Symfony. Elimina tutto all'interno di queste directory. PrestaShop le rigenererà al prossimo caricamento della pagina.

/cache/smarty/compile/ e /cache/smarty/cache/ per le cache dei template Smarty. I template compilati obsoleti sono una causa molto comune di pagine bianche dopo gli aggiornamenti.

/var/cache/prod/class_index.php (o /cache/class_index.php) per la mappa delle classi. Questo file deve essere rigenerato dopo qualsiasi aggiornamento.

Nelle configurazioni PHP-FPM, resetta anche OPcache. OPcache memorizza il bytecode PHP compilato in memoria e potrebbe servire il vecchio codice anche dopo che i file sono stati sostituiti. Riavvia il servizio PHP-FPM o, se non puoi farlo, crea un piccolo file PHP che chiama opcache_reset() e accedici tramite il browser.

Causa Comune 5: Fallimenti della Migrazione del Database

Gli aggiornamenti di PrestaShop spesso includono modifiche allo schema del database: nuove colonne, indici modificati, nuove tabelle o migrazioni di dati. Se il processo di aggiornamento è stato interrotto (timeout, limite di memoria, disconnessione), il database potrebbe trovarsi in uno stato di migrazione parziale.

Controlla il database PrestaShop per la tabella ps_configuration e cerca il valore PS_VERSION_DB. Se questo valore non corrisponde alla versione dei file sul disco, l'aggiornamento non si è completato correttamente. PrestaShop potrebbe tentare di rieseguire le migrazioni al prossimo caricamento, oppure potrebbe semplicemente fallire.

I fallimenti della migrazione del database sono i più difficili da recuperare senza un backup. Se hai un backup del database da prima dell'aggiornamento, ripristinarlo e rieseguire l'aggiornamento è spesso il percorso più sicuro. Se non hai un backup, potresti dover applicare manualmente i file di migrazione SQL mancanti trovati nella directory /install/upgrade/sql/.

Procedura di Ripristino Passo-Passo

Segui questa sequenza quando recuperi da una pagina bianca dopo un aggiornamento core. L'ordine è importante perché ogni passo o risolve il problema o elimina una possibile causa.

Passo 1: Abilita la modalità debug in /config/defines.inc.php impostando _PS_MODE_DEV_ a true. Ricarica la pagina e leggi il messaggio di errore.

Passo 2: Elimina il contenuto di /var/cache/prod/, /var/cache/dev/, /cache/smarty/compile/ e /cache/smarty/cache/. Elimina class_index.php. Ricarica la pagina.

Passo 3: Se l'errore punta a un modulo specifico, disabilita quel modulo rinominando la sua directory o impostando active = 0 nella tabella del database ps_module. Ricarica la pagina.

Passo 4: Se l'errore punta a un file di override, sposta il contenuto della directory /override/ in una posizione di backup temporanea. Elimina di nuovo class_index.php. Ricarica la pagina.

Passo 5: Verifica che la tua versione PHP sia compatibile con la versione di PrestaShop a cui hai aggiornato. Controlla phpinfo() o php -v. Cambia versione PHP se necessario.

Passo 6: Controlla i permessi dei file. Il processo di aggiornamento potrebbe aver creato file con proprietà errata. Tutti i file PrestaShop devono essere leggibili dall'utente del server web, e le directory /var/, /cache/, /img/, /upload/, /download/, /translations/, /themes/ e /modules/ devono essere scrivibili.

Passo 7: Se nessuno dei passaggi precedenti risolve il problema e hai un backup del database, ripristina il database e i file dal backup, poi tenta nuovamente l'aggiornamento dopo aver affrontato eventuali problemi identificati durante la diagnosi.

Procedura di Aggiornamento Sicura per Aggiornamenti Futuri

La prevenzione è di gran lunga migliore del ripristino. Segui questa procedura per ogni aggiornamento del core di PrestaShop per minimizzare il rischio di pagine bianche e perdita di dati.

Prima dell'aggiornamento: Crea un backup completo sia del database che di tutti i file. Non solo il database, non solo i file, ma entrambi. Conserva questi backup in una posizione esterna al tuo account di hosting se possibile. Verifica di poter effettivamente ripristinare da questi backup prima di procedere.

Disabilita tutti i moduli di terze parti. Questo è il singolo passo più efficace che puoi compiere per prevenire le pagine bianche. I moduli core (quelli forniti con PrestaShop) sono progettati per essere compatibili con l'aggiornamento, ma i moduli di terze parti non hanno questa garanzia. Disabilitali prima dell'aggiornamento e riabilitali uno alla volta dopo, testando il negozio dopo ogni riattivazione.

Disabilita il sistema di override. Se hai override personalizzati, disabilitali prima dell'aggiornamento. Rivaluta ogni override dopo l'aggiornamento per determinare se è ancora compatibile e ancora necessario.

Controlla le note di rilascio. Ogni rilascio di PrestaShop include note su requisiti di compatibilità, problemi noti e modifiche che possono causare incompatibilità. Leggile prima di aggiornare, non dopo che qualcosa si è rotto.

Metti il negozio in modalità manutenzione. Questo impedisce ai clienti di effettuare ordini durante l'aggiornamento e di incontrare errori. Naviga in Parametri del Negozio, Generali, Manutenzione nel back office e abilita la modalità manutenzione.

Durante l'aggiornamento: Monitora il processo di aggiornamento. Non chiudere la scheda del browser e non navigare altrove. Se l'aggiornamento richiede più tempo del previsto, controlla i log degli errori del server per errori di timeout o memoria. Se il processo sembra bloccato, attendi almeno 10 minuti prima di intraprendere qualsiasi azione, poiché negozi grandi possono avere migrazioni di database significative da elaborare.

Dopo l'aggiornamento: Svuota tutte le cache. Verifica che il back office si carichi correttamente. Controlla il front office. Riabilita i moduli uno alla volta, controllando il negozio dopo ciascuno. Riabilita gli override uno alla volta se applicabile. Disabilita la modalità manutenzione. Monitora i log degli errori per le successive 24 ore.

Strategie di Rollback

Quando il ripristino non è possibile o richiede troppo tempo, tornare alla versione precedente potrebbe essere l'opzione migliore. Tuttavia, PrestaShop non ha un meccanismo di rollback integrato, quindi devi pianificare questa possibilità prima di iniziare l'aggiornamento.

Rollback completo dal backup: Ripristina sia il database che i file dal backup pre-aggiornamento. Questo è l'approccio più pulito ma richiede che tu abbia fatto un backup completo prima dell'aggiornamento. Dopo il ripristino, verifica che il negozio funzioni correttamente e che nessun ordine o dato cliente creato durante il periodo di aggiornamento fallito sia andato perso (se il negozio era in modalità manutenzione, nulla dovrebbe essere cambiato).

Rollback parziale dei file: Se solo i file sono corrotti ma il database è integro, puoi sostituire i file di PrestaShop con la versione precedente mantenendo il database attuale. Scarica la versione precedente esatta di PrestaShop dall'archivio ufficiale dei rilasci, estraila e sovrascrivi i file sul tuo server. Mantieni i tuoi moduli personalizzati, temi e file di configurazione. Questo approccio è rischioso perché il database potrebbe essere stato parzialmente migrato, creando un'inconsistenza tra i file e lo schema del database.

Fix in avanti: A volte il percorso più veloce non è tornare indietro ma correggere l'errore specifico. Se l'errore è causato da un singolo modulo o override incompatibile, correggere o rimuovere quel singolo componente potrebbe richiedere minuti rispetto alle ore di un rollback completo. Questo approccio è migliore quando hai identificato chiaramente la causa dal messaggio di errore.

L'Importanza dei Backup del Database

Ogni sezione di questa guida menziona i backup, e per una buona ragione. Un database PrestaShop contiene ogni prodotto, ogni ordine, ogni account cliente, ogni impostazione di configurazione e ogni contenuto del tuo negozio. Perderlo significa perdere i dati del tuo business.

I backup giornalieri automatizzati non sono opzionali per un negozio PrestaShop in produzione. Configura il sistema di backup del tuo provider di hosting, usa un modulo di backup del database o imposta un cron job che esegue mysqldump a intervalli regolari. Conserva i backup in più posizioni. Testa periodicamente la tua procedura di ripristino per assicurarti che i backup siano effettivamente utilizzabili.

Prima di qualsiasi aggiornamento, crea un backup manuale in aggiunta ai tuoi backup automatizzati. Nominalo chiaramente con la data e la versione di PrestaShop, in modo da poterlo identificare immediatamente se hai bisogno di ripristinare.

Quando Cercare Aiuto Professionale

Se hai seguito tutti i passi di questa guida e ti trovi ancora di fronte a una pagina bianca, o se i messaggi di errore indicano problemi profondi del core che richiedono correzioni a livello di codice, potrebbe essere il momento di coinvolgere uno sviluppatore PrestaShop. Forniscigli i messaggi di errore che hai raccolto, le versioni di PrestaShop coinvolte (prima e dopo l'aggiornamento), la tua versione PHP e qualsiasi azione che hai già intrapreso. Queste informazioni ridurranno significativamente il tempo necessario per diagnosticare e risolvere il problema.

Tentare di modificare manualmente i file core di PrestaShop senza comprendere l'architettura del framework può creare problemi aggiuntivi. Se il messaggio di errore fa riferimento a container Symfony, dependency injection o configurazione del kernel, queste sono aree in cui modifiche errate possono propagarsi in fallimenti multipli.

Leggi la risposta completa

Come funzionano gli aggiornamenti del carrello in PrestaShop

Prima di affrontare la risoluzione dei problemi, è utile comprendere come PrestaShop gestisce le operazioni del carrello. Quando un cliente clicca su "Aggiungi al carrello", il JavaScript front-end invia una richiesta AJAX al server. Il server elabora la richiesta, aggiorna il carrello nel database e nella sessione, quindi restituisce una risposta JSON contenente il riepilogo aggiornato del carrello. Il JavaScript riceve questa risposta e aggiorna il blocco carrello, la pagina prodotto e tutti gli altri elementi dipendenti dal carrello sulla pagina, senza ricaricare completamente la pagina.

Questo approccio basato su AJAX, introdotto completamente in PrestaShop 1.7, ha sostituito il vecchio metodo di ricaricamento della pagina utilizzato in PrestaShop 1.6. Sebbene offra un'esperienza di acquisto molto più fluida, introduce anche più potenziali punti di errore. Un aggiornamento del carrello può interrompersi a livello JavaScript, a livello di richiesta AJAX, a livello di elaborazione del server o a livello di rendering della risposta. Ogni punto di errore produce sintomi diversi e richiede approcci diagnostici differenti.

In PrestaShop 1.7 e 8.x, il file JavaScript principale responsabile delle operazioni del carrello è core.js, che utilizza jQuery per inviare richieste AJAX al controller del carrello. Il controller del carrello elabora la richiesta e attiva eventi a cui i moduli possono agganciarsi tramite hook. La risposta genera un evento a livello di pagina (updateCart) che tutti i componenti collegati al carrello ascoltano per aggiornare i dati visualizzati.

Sintomo: il clic su Aggiungi al carrello non produce alcun effetto

Quando il clic sul pulsante Aggiungi al carrello non produce assolutamente alcuna risposta, nessuna animazione, nessun indicatore di caricamento, nessun errore, il problema è quasi sempre un errore JavaScript che impedisce l'esecuzione del gestore dell'evento click. L'evento click del pulsante non viene mai intercettato, quindi nessuna richiesta AJAX viene inviata al server.

Apri gli Strumenti per Sviluppatori del browser (F12 oppure Ctrl+Shift+I in Chrome, Firefox ed Edge) e passa alla scheda Console. Ricarica la pagina prodotto e cerca i messaggi di errore in rosso. Gli errori comuni includono $ is not defined oppure jQuery is not defined (jQuery non è stato caricato correttamente), Uncaught TypeError: Cannot read property of undefined (il JavaScript di un modulo fa riferimento a qualcosa che non esiste), oppure Uncaught SyntaxError (un file JavaScript ha un errore di sintassi, spesso da un modulo che non è stato correttamente minificato).

Un singolo errore JavaScript nella pagina può bloccare l'esecuzione di tutto il JavaScript successivo, compresa la funzionalità del carrello. Se un modulo caricato prima del JavaScript core di PrestaShop genera un errore, l'intero sistema del carrello si blocca anche se il modulo non ha nulla a che fare con il carrello.

Per identificare il modulo responsabile, osserva il nome del file nel messaggio di errore. Tipicamente farà riferimento a un percorso come /modules/qualchemodulo/views/js/qualchefile.js. Disabilita temporaneamente quel modulo per confermare che è la causa, quindi contatta lo sviluppatore del modulo per una correzione.

Sintomo: Aggiungi al carrello gira ma non si completa mai

Se il clic su Aggiungi al carrello attiva l'animazione di caricamento ma questa gira all'infinito, la richiesta AJAX è stata inviata ma non ha ricevuto una risposta oppure ha ricevuto una risposta di errore. Passa alla scheda Rete negli Strumenti per Sviluppatori, clicca su Aggiungi al carrello e cerca la richiesta AJAX. Sarà tipicamente una richiesta POST a un URL contenente controller=cart oppure cart nel percorso.

Clicca sulla richiesta per ispezionarla. Controlla la colonna Stato: uno stato 200 con un corpo di risposta vuoto o malformato indica un errore PHP sul server che è stato intercettato prima dell'output. Uno stato 500 indica un errore del server non gestito. Uno stato 403 può indicare un modulo di sicurezza o WAF che blocca la richiesta. Uno stato 408 o timeout indica che il server ha impiegato troppo tempo per rispondere.

Se lo stato è 200 ma il corpo della risposta contiene HTML invece di JSON (cerca i tag HTML nella risposta), significa che PHP ha incontrato un avviso o una notifica che è stata inviata in output prima della risposta JSON, interrompendo il parsing del JSON. Questo è estremamente comune ed è causato da moduli o override che generano testo (anche una riga vuota prima del tag PHP di apertura) durante gli hook di elaborazione del carrello.

Sintomo: il carrello si aggiorna ma mostra dati errati

A volte il carrello sembra funzionare: l'animazione viene riprodotta, l'icona del carrello si aggiorna, ma le quantità, i prezzi o i prodotti visualizzati sono errati. Questo è tipicamente un problema di cache dove il cliente vede dati obsoleti invece del carrello appena calcolato.

PrestaShop ha molteplici livelli di cache, ognuno dei quali può fornire informazioni obsolete sul carrello. Comprendere e controllare sistematicamente ogni livello è essenziale per diagnosticare questo tipo di problema.

Problemi di cache del browser

Il browser stesso può memorizzare nella cache le risposte AJAX o i file JavaScript statici. Sebbene le richieste AJAX POST non dovrebbero essere memorizzate nella cache dai browser, alcune configurazioni di caching aggressive o i service worker possono interferire.

Testa aprendo una finestra in modalità incognito o navigazione privata. Se il carrello funziona correttamente in modalità incognito, il problema è legato alla cache del browser. Istruisci il cliente a svuotare la cache del browser, o più precisamente, prova un aggiornamento forzato con Ctrl+Shift+R (Windows/Linux) oppure Cmd+Shift+R (Mac).

Se il tema PrestaShop utilizza un service worker per la funzionalità di app web progressiva (PWA), il service worker potrebbe intercettare e memorizzare nella cache le richieste AJAX. Controlla la scheda Applicazione negli Strumenti per Sviluppatori, poi Service Workers, per vedere se ne è stato registrato uno. Annulla temporaneamente la registrazione per testare se sta causando il problema.

Anche i file JavaScript statici possono essere memorizzati nella cache. Se hai recentemente aggiornato un modulo che modifica il comportamento del carrello, il browser del cliente potrebbe ancora utilizzare il vecchio file JavaScript. PrestaShop aggiunge una stringa di query di versione agli URL JavaScript (come cart.js?v=1.0.0), ma questo funziona solo se il modulo incrementa correttamente il suo numero di versione durante l'aggiornamento.

Conflitti con la cache di Smarty

PrestaShop utilizza il motore di template Smarty per il rendering dell'HTML lato server. Smarty ha il proprio sistema di compilazione e caching che può fornire output di template obsoleti.

Se i template relativi al carrello sono stati modificati (da un aggiornamento del tema, installazione di un modulo o modifica manuale) ma la cache di Smarty non è stata svuotata, il vecchio template continua ad essere servito. I template compilati sono conservati in /var/cache/prod/smarty/compile/ e l'output in cache in /var/cache/prod/smarty/cache/. L'eliminazione del contenuto di entrambe le directory forza Smarty a ricompilare tutti i template dai file sorgente correnti.

Puoi anche svuotare la cache di Smarty dal back office. Vai su Parametri avanzati, poi Prestazioni, e clicca sul pulsante "Svuota cache". In PrestaShop 8.x, puoi anche utilizzare il pulsante "Svuota cache Symfony" che cancella sia la cache del container Symfony che la cache di Smarty.

Un problema di Smarty più sottile riguarda le impostazioni "Forza compilazione" e "Cache" in Parametri avanzati, Prestazioni, Smarty. Durante lo sviluppo o il debug, imposta la Compilazione dei template su "Forza compilazione" e Cache su "No". Questo garantisce che ogni caricamento della pagina utilizzi i file di template più recenti. Ricorda di ripristinare queste impostazioni su "Ricompila i template se i file sono stati modificati" e "Sì" dopo il debug, poiché la compilazione forzata influisce significativamente sulle prestazioni.

Impostazioni CCC e il loro impatto

La funzione CCC (Combina, Comprimi, Cache) di PrestaShop, che si trova in Parametri avanzati, Prestazioni, unisce e minifica i file CSS e JavaScript per migliorare i tempi di caricamento della pagina. Sebbene sia vantaggiosa per le prestazioni, il CCC può causare problemi al carrello in diversi modi.

Quando il CCC è abilitato, PrestaShop combina più file JavaScript in un singolo file memorizzato nella cache. Se il JavaScript di un modulo dipende dall'ordine di caricamento (deve essere eseguito dopo jQuery ma prima del codice di un altro modulo), il processo di combinazione potrebbe riordinare i file in modo errato, causando il fallimento del codice dipendente.

Il CCC memorizza anche i file combinati in modo aggressivo. Dopo l'installazione, l'aggiornamento o la rimozione di un modulo, il vecchio file combinato potrebbe ancora essere servito. La soluzione è svuotare manualmente la cache CCC andando su Parametri avanzati, Prestazioni, e cliccando su "Svuota cache" oppure eliminando i file memorizzati nella cache in /themes/il_tuo_tema/cache/.

Un problema CCC particolarmente frustrante si verifica quando il file JavaScript di un modulo contiene un errore di sintassi. Quando il CCC lo combina con altri file, l'errore di sintassi interrompe l'intero bundle JavaScript combinato, disabilitando tutta la funzionalità JavaScript della pagina, compreso il carrello. Senza CCC, solo il JavaScript di quel singolo modulo fallirebbe mentre il resto continuerebbe a funzionare. Disabilitare temporaneamente il CCC può aiutare a isolare questo tipo di problema.

Per verificare se il CCC sta causando il tuo problema al carrello, disabilita tutte e tre le opzioni CCC (Smart cache per CSS, Smart cache per JavaScript e ottimizzazione Apache) nelle impostazioni di Prestazioni. Svuota tutte le cache. Se il carrello inizia a funzionare, riabilita le opzioni una alla volta per identificare quale causa il conflitto.

Problemi di cache del CDN

Se il tuo negozio PrestaShop utilizza un CDN (Content Delivery Network) come Cloudflare, KeyCDN o CloudFront, il CDN potrebbe memorizzare nella cache risposte che non dovrebbero essere memorizzate. I CDN sono progettati per memorizzare contenuti statici, ma configurazioni errate possono fare in modo che memorizzino risposte AJAX dinamiche o pagine dipendenti dalla sessione.

Cloudflare in particolare è noto per memorizzare le risposte alle richieste POST quando determinate regole di pagina o regole di cache-everything sono configurate in modo troppo ampio. L'endpoint AJAX del carrello restituisce dati specifici del cliente che non devono mai essere memorizzati nella cache da un CDN.

Per verificare se il CDN è coinvolto, disabilitalo temporaneamente. In Cloudflare, puoi mettere in pausa il CDN o aggiungere una regola di pagina per bypassare temporaneamente la cache per l'intero dominio. Se il carrello funziona correttamente senza il CDN, rivedi le tue regole di caching per assicurarti che gli endpoint AJAX e le pagine dinamiche siano esclusi dalla memorizzazione nella cache.

Per Cloudflare in particolare, assicurati che la regola di pagina "Cache Everything" non copra l'intero dominio. Se devi utilizzarla, aggiungi una regola con priorità più alta che bypassa la cache per gli URL contenenti controller=cart, ajax=true e il percorso del checkout. Verifica anche che il "Browser Cache TTL" non sia impostato troppo alto per gli asset dinamici.

Problemi di cookie e sessione

PrestaShop utilizza i cookie per mantenere la sessione di acquisto, compreso il carrello. Se i cookie non funzionano correttamente, il carrello non può persistere tra le richieste. Ogni aggiornamento AJAX del carrello crea una nuova sessione invece di aggiornare quella esistente, con il risultato di un carrello che appare vuoto dopo ogni caricamento della pagina.

I problemi comuni dei cookie includono: il dominio del cookie è mal configurato (il cookie è impostato per www.esempio.com ma la richiesta AJAX va a esempio.com senza il prefisso www, o viceversa), il percorso del cookie è errato, l'attributo SameSite è impostato su Strict che blocca i cookie in determinati scenari cross-origin, oppure il cookie è troppo grande e viene rifiutato dal browser (i browser tipicamente limitano la dimensione dei cookie a 4KB).

Controlla i cookie nella scheda Applicazione degli Strumenti per Sviluppatori. Cerca il cookie di sessione PrestaShop (chiamato PrestaShop-[hash] nelle versioni più recenti). Verifica che abbia il dominio e il percorso corretti e che venga inviato con le richieste AJAX (controlla l'header Cookie nella scheda Rete per la richiesta AJAX del carrello).

Nelle configurazioni multi-dominio o multi-negozio, i problemi di cookie sono particolarmente comuni. Se il negozio è accessibile sia tramite http che https, o sia con www che senza www, il cookie potrebbe non essere condiviso tra queste varianti. Assicurati che il tuo negozio utilizzi un singolo URL canonico e che tutte le altre varianti reindirizzino ad esso.

Anche i problemi del certificato SSL possono impedire il funzionamento dei cookie. Se il flag Secure è impostato sul cookie ma la pagina viene caricata tramite HTTP (o contenuto misto), il browser non invierà il cookie. Assicurati che l'intero negozio sia servito tramite HTTPS in modo coerente.

Conflitti tra moduli: processo di diagnosi

I conflitti tra moduli sono la causa più comune dei problemi al carrello in PrestaShop. Due o più moduli possono agganciarsi agli stessi eventi del carrello e interferire tra loro, oppure un singolo modulo può avere un bug che corrompe la risposta del carrello.

L'approccio sistematico per diagnosticare i conflitti tra moduli prevede la disabilitazione dei moduli in gruppi. Inizia disabilitando tutti i moduli di terze parti (mantieni attivi i moduli nativi di PrestaShop). Se il carrello funziona, riabilita i moduli in gruppi di 5. Quando il problema si ripresenta, hai ristretto il campo a 5 moduli. Disabilita quei 5 e riabilitali uno alla volta per trovare il colpevole esatto.

Presta particolare attenzione ai moduli che si agganciano a questi hook di PrestaShop, poiché influenzano direttamente il comportamento del carrello: actionCartSave, actionCartUpdate, displayShoppingCart, displayShoppingCartFooter, actionBeforeCartUpdateQty, actionAfterCartUpdateQty, displayHeader (i moduli che aggiungono JavaScript qui possono entrare in conflitto con il JS del carrello) e actionFrontControllerSetMedia.

Per vedere quali moduli sono registrati sugli hook relativi al carrello, controlla il database:

SELECT h.name, m.name FROM ps_hook_module hm JOIN ps_hook h ON h.id_hook = hm.id_hook JOIN ps_module m ON m.id_module = hm.id_module WHERE h.name LIKE '%cart%' ORDER BY h.name, hm.position;

Questa query elenca tutti i moduli agganciati agli hook relativi al carrello, insieme al loro ordine di esecuzione. I conflitti sorgono spesso quando due moduli tentano entrambi di modificare il totale del carrello o applicare sconti in modi incompatibili.

Debug con gli Strumenti per Sviluppatori del browser: guida passo dopo passo

Gli Strumenti per Sviluppatori del browser sono l'arma più potente per diagnosticare i problemi del carrello. Ecco una guida dettagliata passo dopo passo su come utilizzarli efficacemente.

Passo 1: Apri gli Strumenti per Sviluppatori e vai alla scheda Console. Cancella tutti i messaggi esistenti. Ricarica la pagina prodotto. Annota eventuali errori o avvisi che compaiono. Questi sono problemi preesistenti che possono essere collegati o meno al problema del carrello, ma dovrebbero essere documentati.

Passo 2: Passa alla scheda Rete. Seleziona la casella "Mantieni registro" in modo che le richieste non vengano cancellate durante la navigazione. Filtra per "XHR" o "Fetch" per vedere solo le richieste AJAX. Clicca sul pulsante Aggiungi al carrello.

Passo 3: Esamina la richiesta AJAX. Clicca sulla richiesta del carrello che appare. Nella sotto-scheda Intestazioni, verifica che l'URL della richiesta sia corretto e che il Codice di stato sia 200. Nella sotto-scheda Payload della richiesta o Dati del modulo, verifica che l'ID del prodotto, la quantità e la combinazione di attributi corretti vengano inviati.

Passo 4: Controlla la risposta. Passa alla sotto-scheda Risposta o Anteprima. La risposta dovrebbe essere JSON valido. Se vedi HTML mescolato, un errore o avviso PHP viene inviato in output. Se la risposta è vuota, l'elaborazione lato server si è bloccata prima di generare l'output. Se il JSON è valido ma contiene messaggi di errore, leggili per trovare indizi.

Passo 5: Controlla la Console dopo la risposta AJAX. Gli errori JavaScript che si verificano durante l'elaborazione della risposta AJAX appariranno nella Console dopo il completamento della richiesta di rete. Questi errori indicano che la risposta è stata ricevuta ma non è stata elaborata correttamente dal JavaScript front-end.

Considerazioni specifiche per PrestaShop 8.x

PrestaShop 8.x utilizza un'architettura front-end significativamente aggiornata rispetto alla 1.7. Il JavaScript del carrello è stato rielaborato e parte del codice precedentemente dipendente da jQuery ora utilizza JavaScript nativo o metodi jQuery aggiornati. I moduli scritti per PrestaShop 1.7 che manipolano direttamente il DOM del carrello potrebbero fallire sulla 8.x perché la struttura HTML e i nomi delle classi CSS sono cambiati.

L'integrazione di Symfony in PrestaShop 8.x significa anche che la pulizia della cache è più articolata. La cache del container Symfony, situata in /var/cache/prod/ e /var/cache/dev/, può contenere definizioni di servizi compilate e mappature delle rotte che influenzano il modo in cui i controller del carrello elaborano le richieste. Svuotare solo la cache di Smarty non è sufficiente; è necessario svuotare anche la cache di Symfony.

PrestaShop 8.x ha anche introdotto header Content Security Policy (CSP) più restrittivi in alcune configurazioni. Se il tuo server o un modulo di sicurezza aggiunge header CSP che limitano il JavaScript inline o le richieste AJAX a domini specifici, le chiamate AJAX del carrello potrebbero essere bloccate. Controlla la Console per i messaggi di violazione CSP, che appaiono come errori rossi che menzionano "Content Security Policy".

Problemi lato server: sessioni PHP e configurazione

La configurazione delle sessioni PHP può causare problemi al carrello difficili da diagnosticare perché appaiono in modo intermittente. Se la directory di archiviazione delle sessioni è piena, ha permessi errati o si trova su un filesystem che non supporta il blocco dei file, le sessioni possono essere perse o corrotte tra le richieste.

Controlla la configurazione delle sessioni PHP: session.save_path deve puntare a una directory scrivibile con spazio su disco sufficiente. session.gc_maxlifetime controlla per quanto tempo le sessioni vengono mantenute; se impostato troppo basso, i clienti perdono i loro carrelli durante sessioni di navigazione prolungate. session.cookie_lifetime dovrebbe corrispondere o superare il valore di gc_maxlifetime.

Sull'hosting condiviso con molti siti, la directory delle sessioni potrebbe contenere milioni di file da tutti i siti ospitati, rendendo lento l'accesso ai file di sessione. Se il tuo fornitore di hosting lo supporta, configura una directory di sessione per sito o utilizza sessioni basate su database.

Per i negozi che utilizzano più server web dietro un load balancer, le sessioni devono essere condivise tra i server. Se l'archiviazione delle sessioni è basata su file e locale a ciascun server, la richiesta successiva di un cliente potrebbe colpire un server diverso che non ha la sua sessione, con il risultato di un carrello vuoto. Utilizza un archivio di sessioni condiviso come Redis, Memcached o sessioni nel database negli ambienti con bilanciamento del carico.

Checklist diagnostica passo dopo passo

Quando un cliente segnala che il carrello non si aggiorna, segui questa checklist in ordine:

1. Riproduci il problema. Prova a replicare il problema in una finestra in incognito utilizzando lo stesso prodotto e browser segnalato dal cliente. Se non riesci a riprodurlo, chiedi al cliente la versione del browser, il tipo di dispositivo e i passaggi esatti.

2. Controlla la console del browser per errori JavaScript. Qualsiasi messaggio di errore in rosso è potenzialmente la causa, anche se sembra non essere collegato al carrello.

3. Controlla la richiesta di rete. Verifica che la richiesta AJAX venga inviata, restituisca uno stato 200 e contenga JSON valido.

4. Svuota tutte le cache: cache di compilazione Smarty, cache di Smarty, cache di Symfony, cache CCC, OPcache e cache CDN se applicabile.

5. Disabilita il CCC. Se il carrello funziona con il CCC disabilitato, la causa è un errore nella combinazione JavaScript.

6. Testa con il tema predefinito. Passa temporaneamente al tema predefinito Classic di PrestaShop. Se il carrello funziona sul tema predefinito, il problema è nel JavaScript o nei template del tuo tema personalizzato.

7. Disabilita i moduli di terze parti. Se il carrello funziona con tutti i moduli di terze parti disabilitati, utilizza il metodo di ricerca binaria per identificare il modulo in conflitto.

8. Controlla i log degli errori PHP. Gli errori lato server che non raggiungono il browser vengono registrati qui.

9. Verifica la configurazione dei cookie e delle sessioni. Controlla il cookie di sessione negli Strumenti per Sviluppatori e verifica le impostazioni delle sessioni PHP sul server.

10. Testa su un dispositivo e una rete diversi. Questo elimina problemi locali del browser, proxy di rete e problemi di compatibilità JavaScript specifici del dispositivo come potenziali cause.

Leggi la risposta completa

Perche i log degli errori di PrestaShop sono importanti

Ogni negozio PrestaShop genera errori. Alcuni sono avvisi innocui che non influenzano mai i tuoi clienti. Altri sono guasti critici che bloccano completamente il checkout. La differenza tra un proprietario di negozio che passa giorni in attesa del supporto e uno che risolve i problemi in pochi minuti si riduce spesso a una singola competenza: saper leggere i log degli errori.

I log degli errori sono l'output diagnostico del tuo server e della tua applicazione PrestaShop. Registrano ogni errore PHP, ogni query del database fallita, ogni problema di permessi e ogni eccezione non gestita. Quando qualcosa va storto, la risposta si trova quasi sempre in un file di log. La sfida sta nel sapere dove cercare, cosa cercare e come interpretare cio che trovi.

Questa guida copre l'intero panorama del logging degli errori in PrestaShop. Imparerai dove si trova ogni tipo di log, come abilitare la segnalazione dettagliata degli errori, come leggere gli stack trace e come utilizzare gli strumenti da riga di comando per trovare l'ago nel pagliaio. Che tu stia facendo debug di uno schermo bianco della morte o cercando di rintracciare un errore intermittente al checkout, queste sono le conoscenze di cui hai bisogno.

Dove si trovano i log di PrestaShop

PrestaShop genera log a diversi livelli, e ogni livello ha i propri file di log. Capire quale log controllare per primo consente di risparmiare enormi quantita di tempo.

Log dell'applicazione PrestaShop (var/logs)

A partire da PrestaShop 1.7, l'applicazione utilizza il framework Symfony per il back office e il routing principale. Symfony scrive i propri log nella directory var/logs/ nella root di PrestaShop. Troverai file denominati in base all'ambiente corrente:

var/logs/dev.log contiene i log quando PrestaShop viene eseguito in modalita di sviluppo. Questo file e estremamente dettagliato e registra tutto, dalle decisioni di routing alle query del database. Puo crescere fino a centinaia di megabyte rapidamente.

var/logs/prod.log contiene i log dalla modalita di produzione. Questo file e molto meno dettagliato per impostazione predefinita, registrando solo avvisi ed errori. Questo e il file che dovresti controllare per primo quando qualcosa si rompe in un negozio live.

Questi file di log seguono il formato Monolog, che e la libreria di logging standard in Symfony. Ogni riga include un timestamp, il canale del log (come request, security o doctrine), il livello di gravita e il messaggio. Una voce tipica appare cosi:

[2024-03-15 14:22:33] request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "No route found for GET /admin/nonexistent" at /var/www/html/vendor/symfony/http-kernel/EventListener/RouterListener.php line 136

I livelli di gravita, dal meno al piu grave, sono: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT e EMERGENCY. Quando risolvi problemi, filtra prima per ERROR e CRITICAL.

Log degli errori PHP

PHP stesso mantiene un log degli errori separato dai log dell'applicazione PrestaShop. Questo log cattura gli errori che si verificano prima che il framework di logging di PrestaShop si inizializzi, o errori nel codice che non utilizza il logger Symfony. La posizione di questo file dipende dalla configurazione del server.

Sulla maggior parte dei server Linux con Apache, il log degli errori PHP si trova in /var/log/php_errors.log o /var/log/php/error.log. Sull'hosting condiviso con cPanel, si trova spesso in /home/nomeutente/logs/error.log o nella directory public_html come error_log.

Puoi trovare la posizione esatta controllando la configurazione PHP. Crea un file PHP temporaneo con phpinfo(); e cerca la direttiva error_log. In alternativa, esegui php -i | grep error_log dalla riga di comando.

I log degli errori PHP catturano errori fatali, errori di parsing, avvisi e notifiche. Una voce di errore fatale tipicamente appare cosi:

[15-Mar-2024 14:22:33 UTC] PHP Fatal error: Uncaught Error: Class 'SomeModule\SomeClass' not found in /var/www/html/modules/somemodule/somemodule.php:45

Log del web server (Apache e Nginx)

Il tuo web server mantiene i propri set di log indipendenti da PHP e PrestaShop. Questi log sono essenziali per diagnosticare errori 500, errori 404 e problemi di prestazioni.

I log di Apache si trovano tipicamente in:

/var/log/apache2/error.log per il log degli errori su sistemi Debian e Ubuntu.
/var/log/httpd/error_log per il log degli errori su sistemi CentOS e RHEL.
/var/log/apache2/access.log per il log degli accessi, che registra ogni richiesta HTTP.

I log di Nginx si trovano tipicamente in:

/var/log/nginx/error.log per il log degli errori.
/var/log/nginx/access.log per il log degli accessi.

Se il tuo sito utilizza una configurazione di virtual host, i log potrebbero trovarsi in una posizione specifica del sito definita dalla direttiva ErrorLog (Apache) o error_log (Nginx) nel file del virtual host.

I log degli errori del web server catturano problemi come errori di permesso negato quando PHP tenta di scrivere in una directory, errori di sintassi nella configurazione dopo una modifica di .htaccess e errori di timeout del proxy se stai eseguendo PHP-FPM dietro Nginx. Questi sono i log da controllare quando vedi un generico errore 500 Internal Server Error senza dettagli nei log PHP o PrestaShop.

Log legacy di PrestaShop (Back Office)

PrestaShop mantiene anche un visualizzatore di log all'interno del back office sotto Parametri avanzati > Log. Questa interfaccia mostra le voci di log archiviate nella tabella del database ps_log. Questi log catturano eventi che PrestaShop registra esplicitamente, come tentativi di login falliti, errori di installazione dei moduli e errori nell'invio delle email.

Sebbene il visualizzatore di log del back office sia comodo, ha limitazioni significative. Non cattura errori PHP, errori del web server o la maggior parte degli errori fatali che impediscono il caricamento della pagina. Consideralo un supplemento ai log basati su file, non un sostituto.

Abilitare la modalita debug in PrestaShop

Per impostazione predefinita, PrestaShop viene eseguito in modalita produzione e nasconde i messaggi di errore dettagliati ai visitatori. Questo e corretto per un negozio live, ma rende il debug quasi impossibile. Quando qualcosa si rompe, il primo passo dovrebbe essere abilitare la modalita debug.

Metodo 1: il file defines.inc.php

Apri il file config/defines.inc.php e cerca la riga che imposta _PS_MODE_DEV_. Cambiala da false a true:

define('_PS_MODE_DEV_', true);

Questa singola modifica ha diversi effetti. La segnalazione degli errori PHP viene impostata al livello massimo, mostrando tutti gli errori, avvisi e notifiche. La cache dei template Smarty viene disabilitata, cosi le modifiche ai template appaiono immediatamente. La barra del profiler Symfony appare in fondo alle pagine del back office. E soprattutto, i dettagli degli errori vengono mostrati sullo schermo invece di mostrare una pagina di errore generica.

Metodo 2: la modalita Debug Profiling

Per un'analisi piu approfondita, puoi anche abilitare il profiling. Nello stesso file, imposta:

define('_PS_DEBUG_PROFILING_', true);

Questo aggiunge informazioni dettagliate su tempi e utilizzo della memoria in fondo a ogni pagina, mostrando quali hook richiedono piu tempo, quali moduli consumano piu memoria e quante query al database genera ogni pagina. Questo e inestimabile per il debug delle prestazioni ma non dovrebbe mai essere lasciato attivo in produzione.

Avviso di sicurezza

La modalita debug espone informazioni sensibili tra cui percorsi dei file, credenziali del database negli stack trace e struttura interna dell'applicazione. Non lasciare mai la modalita debug abilitata su un negozio in produzione accessibile al pubblico. Se hai bisogno di fare debug di un negozio live, considera la possibilita di limitare la modalita debug al tuo indirizzo IP racchiudendo il define in un controllo dell'IP, oppure utilizza un ambiente di staging.

Leggere gli stack trace

Quando PrestaShop incontra un errore fatale o un'eccezione non gestita in modalita debug, visualizza uno stack trace. Uno stack trace e un'istantanea della catena di chiamate che ha portato all'errore, che si legge dal punto di errore all'indietro fino al punto di ingresso originale. Imparare a leggere gli stack trace e la singola competenza di debug piu preziosa che puoi sviluppare.

Anatomia di uno stack trace

Un tipico stack trace di PrestaShop appare cosi:

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Product::getProductProperties() must be of the type int, null given, called in /var/www/html/classes/Product.php on line 4523

Stack trace: #0 /var/www/html/classes/Product.php(4523): Product::getProductProperties(NULL, Array) #1 /var/www/html/modules/somemodule/somemodule.php(127): Product::getProductProperties(1, Array) #2 /var/www/html/classes/Hook.php(523): SomeModule->hookDisplayHome(Array) #3 /var/www/html/classes/Hook.php(460): Hook::coreCallHook(Object(SomeModule), 'hookDisplayHome', Array) #4 /var/www/html/classes/Hook.php(408): Hook::exec('displayHome', Array)

Leggi lo stack trace dall'alto verso il basso. La prima riga ti dice cosa e andato storto: una funzione si aspettava un intero ma ha ricevuto null. La riga #0 ti dice dove si e verificato l'errore. La riga #1 ti dice cosa ha chiamato il codice alla riga #0. La riga #2 ti dice cosa ha chiamato #1, e cosi via.

In questo esempio, la catena e chiara: PrestaShop ha eseguito l'hook displayHome, che ha chiamato il metodo hookDisplayHome in SomeModule, che ha chiamato Product::getProductProperties() con un valore null dove era previsto un intero. Il bug si trova nel modulo alla riga 127, dove passa un valore errato.

Trovare il frame rilevante

Gli stack trace in PrestaShop possono essere lunghi, a volte 20 o 30 frame di profondita. La chiave e trovare il frame che contiene il tuo codice o il modulo che causa il problema. Cerca percorsi contenenti /modules/ o /themes/ perche queste sono le fonti piu probabili di bug. I frame che fanno riferimento a /classes/, /src/ o /vendor/ sono codice core di PrestaShop o librerie di terze parti, che hanno meno probabilita di essere la fonte del problema a meno che tu non abbia modificato i file core.

Pattern di errore comuni in PrestaShop

Dopo aver letto migliaia di log degli errori di PrestaShop, emergono ripetutamente certi pattern. Riconoscere questi pattern ti permette di diagnosticare problemi in pochi secondi invece che in ore.

Errori Class Not Found

PHP Fatal error: Uncaught Error: Class 'ModuleName\ClassName' not found

Questo significa che l'autoloader non riesce a trovare la classe specificata. Le cause comuni includono: un file vendor/autoload.php mancante (il modulo necessita di composer install), una dichiarazione di namespace non corrispondente, un file che non e stato incluso nello ZIP del modulo durante l'installazione, o un problema di case sensitivity sui server Linux dove ClassName.php e classname.php sono file diversi.

Errori Permission Denied

Warning: file_put_contents(/var/www/html/var/cache/prod/some_file): failed to open stream: Permission denied

Questi si verificano quando l'utente del web server (solitamente www-data su Debian/Ubuntu o apache su CentOS) non ha il permesso di scrittura su un file o directory. Correggi questo correggendo la proprieta: chown -R www-data:www-data var/cache/ e i permessi: chmod -R 775 var/cache/.

Errori Memory Limit

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes)

Il numero 134217728 byte equivale a 128MB, che e il limite di memoria PHP predefinito. PrestaShop raccomanda almeno 256MB. Aumentalo nel file php.ini: memory_limit = 512M. Se l'errore persiste anche con limiti di memoria elevati, il codice probabilmente ha un memory leak, spesso causato dal caricamento di troppi prodotti o categorie in una singola query senza paginazione.

Errori di connessione al database

Link to database cannot be established: SQLSTATE[HY000] [2002] Connection refused

Questo significa che PrestaShop non riesce a connettersi al server MySQL. Verifica che il server del database sia in esecuzione, che le credenziali in app/config/parameters.php siano corrette e che l'host del database sia raggiungibile dal web server.

Errori dei template Smarty

SmartyException: Unable to load template file 'module:somemodule/views/templates/hook/display.tpl'

Il file del template e mancante, scritto male o nella directory sbagliata. Verifica che il file esista nel percorso previsto e che il nome del file corrisponda esattamente, incluso il maiuscolo/minuscolo.

Errori del token CSRF

Invalid token. Please try to log in again.

Questo appare nel back office quando l'invio di un modulo include un token di sicurezza scaduto o mancante. Succede tipicamente quando una sessione scade durante una lunga sessione di modifica, quando piu schede sono aperte sulla stessa pagina admin, o quando un modulo genera i propri URL del modulo in modo errato.

Usare grep per trovare errori

Quando i file di log sono grandi, scorrerli manualmente e poco pratico. Il comando grep e il tuo migliore alleato per trovare rapidamente le voci rilevanti.

Ricerca base degli errori

Per trovare tutti gli errori fatali nel log degli errori PHP:

grep 'Fatal error' /var/log/php_errors.log

Per trovare errori di un modulo specifico:

grep 'somemodule' /var/www/html/var/logs/prod.log

Per trovare errori solo di oggi (assumendo il formato della data nel log):

grep '2024-03-15' /var/www/html/var/logs/prod.log | grep 'ERROR\|CRITICAL'

Filtraggio avanzato

Per vedere gli errori con contesto circostante (3 righe prima e dopo ogni corrispondenza):

grep -C 3 'Fatal error' /var/log/php_errors.log

Per contare quante volte si verifica ogni errore unico:

grep 'Fatal error' /var/log/php_errors.log | sort | uniq -c | sort -rn | head -20

Questa pipeline ordina gli errori, conta i duplicati, ordina per conteggio in ordine decrescente e mostra i primi 20. Questo e incredibilmente utile per identificare gli errori piu frequenti che richiedono attenzione per primi.

Per cercare attraverso piu file di log contemporaneamente:

grep -r 'Fatal error' /var/log/ --include='*.log'

Il flag -r cerca ricorsivamente e --include limita la ricerca ai file con estensione .log.

Monitoraggio dei log in tempo reale con tail -f

Quando stai attivamente facendo debug di un problema, hai bisogno di vedere gli errori nel momento in cui si verificano. Il comando tail -f segue un file di log in tempo reale, mostrando le nuove voci man mano che vengono scritte.

Monitoraggio base in tempo reale

Per monitorare il log di produzione di PrestaShop in tempo reale:

tail -f /var/www/html/var/logs/prod.log

Per monitorare il log degli errori PHP:

tail -f /var/log/php_errors.log

Per monitorare piu file di log contemporaneamente:

tail -f /var/www/html/var/logs/prod.log /var/log/php_errors.log /var/log/apache2/error.log

Monitoraggio filtrato in tempo reale

Per monitorare solo le voci di livello errore in tempo reale, combina tail con grep:

tail -f /var/www/html/var/logs/prod.log | grep --line-buffered 'ERROR\|CRITICAL'

Il flag --line-buffered e importante qui. Senza di esso, grep bufferizza il suo output e potresti non vedere le corrispondenze immediatamente.

Per evidenziare parole chiave specifiche mostrando tutto l'output:

tail -f /var/www/html/var/logs/prod.log | grep --color=always -E 'ERROR|CRITICAL|$'

Questo evidenzia ERROR e CRITICAL a colori mostrando comunque tutte le righe.

Il flusso di lavoro del debug

Il flusso di lavoro di debug piu efficace combina il monitoraggio in tempo reale con il test attivo. Apri una finestra del terminale con tail -f in esecuzione sui file di log rilevanti. Nel browser, riproduci l'azione che causa l'errore. Osserva il terminale per le nuove voci di log che appaiono nell'esatto momento in cui attivi il problema. Questo approccio elimina le congetture e ti mostra precisamente cosa succede quando si verifica l'errore.

Rotazione e gestione dei log

I file di log crescono continuamente e possono consumare tutto lo spazio disco disponibile se lasciati senza gestione. La maggior parte dei server Linux utilizza logrotate per gestire questo automaticamente, ma i log propri di PrestaShop in var/logs/ potrebbero non essere inclusi nella configurazione predefinita di logrotate.

Comprendere Logrotate

L'utilita logrotate viene eseguita giornalmente (solitamente tramite cron) e gestisce la rotazione, la compressione e l'eliminazione dei file di log. I file di configurazione si trovano in /etc/logrotate.d/. La rotazione dei log di Apache e Nginx e tipicamente configurata di default.

Per la directory var/logs di PrestaShop, potrebbe essere necessario creare una configurazione logrotate personalizzata:

/var/www/html/var/logs/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data www-data }

Questa configurazione ruota i log giornalmente, mantiene 14 giorni di storia, comprime i log vecchi e crea nuovi file di log con i permessi corretti.

Pulizia manuale dei log

Se un file di log e cresciuto enormemente e hai bisogno di svuotarlo senza perdere l'handle del file (importante se un processo sta attivamente scrivendo su di esso):

truncate -s 0 /var/www/html/var/logs/prod.log

Non eliminare il file e ricrearlo, perche qualsiasi processo che ha il file aperto continuera a scrivere sull'inode del file eliminato fino al riavvio. L'approccio con truncate svuota i contenuti preservando l'inode.

Comprendere i contesti di errore specifici di PrestaShop

Gli errori di PrestaShop spesso arrivano con un contesto unico per la piattaforma. Comprendere questo contesto ti aiuta a localizzare e correggere i problemi piu velocemente.

Errori relativi agli hook

Quando un errore si verifica all'interno di un hook, lo stack trace includera riferimenti a Hook::exec() e Hook::coreCallHook(). Il nome dell'hook ti dice esattamente in quale momento del processo di rendering della pagina si verifica l'errore. Per esempio, gli errori displayHome si verificano nella homepage, gli errori actionValidateOrder si verificano durante il checkout, e gli errori displayBackOfficeHeader si verificano quando si carica qualsiasi pagina del back office.

Se un errore in un hook manda in crash una pagina, puoi disabilitare temporaneamente il modulo responsabile dal database:

UPDATE ps_module SET active = 0 WHERE name = 'somemodule';

Questo ti permette di accedere al back office per diagnosticare e correggere correttamente il problema.

Conflitti degli override

Il sistema di override di PrestaShop permette ai moduli di estendere le classi core, ma sorgono conflitti quando due moduli fanno override della stessa classe. L'errore appare tipicamente come un conflitto nella firma del metodo o un cambiamento di comportamento inatteso. Controlla la directory override/ per vedere quali override sono attivi e controlla il file cache/class_index.php che mappa le classi ai loro file di override. Eliminare questo file di cache forza PrestaShop a rigenerare la mappa degli override.

Errori relativi alla cache

Molti errori di PrestaShop sono causati da file di cache obsoleti. Se vedi errori che non corrispondono al codice corrente (per esempio, un errore che fa riferimento a un numero di riga che non esiste nel file), la cache e probabilmente obsoleta. Svuotala eliminando i contenuti di var/cache/prod/ e var/cache/dev/. Su PrestaShop 1.6, svuota invece cache/smarty/compile/ e cache/smarty/cache/.

Errori di installazione e aggiornamento dei moduli

Le installazioni dei moduli possono fallire silenziosamente, lasciando il modulo in uno stato parzialmente installato. Controlla var/logs/prod.log per le voci durante il timestamp dell'installazione. I problemi comuni includono tabelle del database mancanti (l'SQL nel metodo install() del modulo e fallito), hook mancanti (la chiamata registerHook() e fallita) e errori di voce duplicata nella tabella ps_authorization_role quando si reinstalla un modulo che non e stato completamente disinstallato.

Costruire una checklist di debug

Quando incontri un errore in PrestaShop, segui questa checklist sistematica per trovare la causa in modo efficiente:

Primo, identifica il tipo di errore. E uno schermo bianco (errore 500), un messaggio di errore specifico, un layout rotto o un comportamento inatteso? Ogni tipo indica file di log diversi.

Secondo, controlla prima il log piu specifico. Per gli errori PHP, controlla il log degli errori PHP. Per gli errori HTTP, controlla il log degli errori del web server. Per gli errori dell'applicazione, controlla var/logs/prod.log.

Terzo, abilita la modalita debug se i log non rivelano informazioni sufficienti. Cambia _PS_MODE_DEV_ a true e riproduci l'errore.

Quarto, usa tail -f sui log rilevanti e riproduci l'errore nel browser. Questo ti fornisce una visualizzazione in tempo reale di esattamente cosa succede.

Quinto, leggi lo stack trace dall'alto verso il basso. Trova il frame che fa riferimento al codice del tuo modulo o tema. E li che deve essere applicata la correzione.

Sesto, cerca il messaggio di errore nelle issue di GitHub di PrestaShop e nei forum. E molto probabile che qualcuno abbia incontrato e risolto lo stesso problema prima.

Settimo, dopo aver applicato una correzione, svuota tutte le cache e monitora i log per confermare che l'errore sia scomparso. Una correzione che non produce un log pulito non e una correzione completa.

Riepilogo

Leggere i log degli errori di PrestaShop non e un'arte misteriosa riservata agli sviluppatori senior. E una competenza pratica costruita sulla conoscenza di dove si trovano i log, come filtrarli e come interpretare cio che contengono. I log in var/logs/, il log degli errori PHP e il log del web server servono ciascuno uno scopo diverso e insieme forniscono un quadro completo di qualsiasi problema. Abilitare la modalita debug ti fornisce messaggi di errore dettagliati. Gli stack trace ti mostrano l'esatta catena di chiamate di funzione che ha portato all'errore. Strumenti come grep e tail -f rendono possibile trovare e monitorare gli errori in modo efficiente anche in file di log grandi e molto attivi. Padroneggia queste tecniche e risolverai i problemi piu velocemente, con meno frustrazione e con molta meno dipendenza dal supporto esterno.

Leggi la risposta completa

Capire i codici di errore HTTP in PrestaShop

I codici di errore HTTP sono risposte standardizzate dal tuo server web che indicano che qualcosa è andato storto quando un browser o un bot di un motore di ricerca ha tentato di accedere a una pagina. Per i proprietari di negozi PrestaShop, questi errori possono significare vendite perse, clienti frustrati e posizionamenti SEO danneggiati.

Errore 403 - Vietato

Un errore 403 significa che il server ha capito la tua richiesta ma rifiuta di autorizzarla. È tipicamente un problema di permessi o controllo degli accessi.

1. Permessi di file e directory non corretti

Le directory devono essere impostate a 755 e i file a 644.

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

2. Regole .htaccess che bloccano l'accesso

Un file .htaccess troppo restrittivo può bloccare richieste legittime.

3. ModSecurity o WAF che bloccano richieste

I firewall delle applicazioni web possono produrre falsi positivi.

Risolvere gli errori 403

Controllare e correggere i permessi dei file
Esaminare .htaccess per regole troppo restrittive
Controllare i log di sicurezza dell'hosting
Verificare che il proprio IP non sia in una lista nera

Errore 404 - Non trovato

Un errore 404 significa che il server non riesce a trovare la pagina richiesta.

1. URL amichevoli disabilitati o mal configurati

Vai a Parametri del negozio > Traffico e SEO, assicurati che gli URL amichevoli siano abilitati e clicca Salva. Verifica che mod_rewrite sia abilitato sul server.

2. Prodotti o categorie eliminati senza redirect

Configura sempre redirect 301 quando rimuovi contenuti.

3. .htaccess mancante o corrotto

Rigenera l'.htaccess da Parametri del negozio > Traffico e SEO.

Risolvere gli errori 404

Verificare che .htaccess esista ed sia configurato correttamente
Verificare che mod_rewrite sia abilitato
Rigenerare l'.htaccess
Configurare redirect 301
Controllare Google Search Console per errori di scansione

Errore 500 - Errore interno del server

Un errore 500 significa che qualcosa è andato storto lato server.

1. Limite di memoria PHP superato

memory_limit = 512M

2. Errori di sintassi PHP o errori fatali

define('_PS_MODE_DEV_', true);

3. Incompatibilità versione PHP

PrestaShop	PHP Minimo	PHP Raccomandato
1.7.x	7.1	7.4
8.x	7.2	8.1
9.x	8.1	8.2+

4. Problemi di connessione al database

Verifica le credenziali in app/config/parameters.php.

5. Conflitti tra moduli

mv modules/problematic_module modules/problematic_module_disabled

Risolvere gli errori 500

Abilitare la modalità debug
Controllare il log errori PHP
Aumentare il limite di memoria PHP
Verificare la compatibilità della versione PHP
Disabilitare i moduli installati di recente

Errore 503 - Servizio non disponibile

Un errore 503 significa che il server è temporaneamente impossibilitato a gestire la richiesta.

1. Modalità manutenzione ancora attiva

UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SHOP_ENABLE';

2. Sovraccarico del server

Aggiornare il piano di hosting
Abilitare il caching di PrestaShop
Usare un CDN come Cloudflare
Abilitare OPcache per PHP

3. Esaurimento worker PHP-FPM

pm = dynamic
pm.max_children = 50
pm.start_servers = 10

Risolvere gli errori 503

Controllare e disabilitare la modalità manutenzione
Monitorare le risorse del server
Controllare i log PHP-FPM
Rivedere la programmazione dei cron job
Considerare un hosting più performante

Consigli generali di debug

Apache - /var/log/apache2/error.log
Nginx - /var/log/nginx/error.log
PHP-FPM - /var/log/php-fpm/error.log
PrestaShop - /var/logs/

Dopo ogni correzione, svuotare tutte le cache.

Leggi la risposta completa

Come PrestaShop utilizza i cookie

Ogni negozio PrestaShop si basa sui cookie per funzionare. Mantengono le sessioni dei clienti, ricordano il contenuto del carrello, memorizzano le preferenze di lingua e valuta, tracciano lo stato di accesso e consentono al back office di autenticare gli amministratori. Senza cookie, un negozio PrestaShop non può mantenere lo stato tra i caricamenti delle pagine, il che significa nessun carrello, nessun login del cliente e nessun accesso all'amministrazione.

PrestaShop utilizza due cookie principali. Il cookie del front office, tipicamente denominato in base al tuo negozio (come PrestaShop-abc123), gestisce tutto ciò che riguarda il lato cliente. Il cookie del back office, con un pattern di denominazione simile ma un ambito diverso, gestisce l'autenticazione degli amministratori. Entrambi i cookie memorizzano dati serializzati direttamente nel valore del cookie, una scelta progettuale che ha implicazioni significative per le prestazioni, la sicurezza e la conformità al GDPR.

Struttura e contenuto dei cookie di PrestaShop

A differenza di molte applicazioni web che memorizzano solo un ID di sessione nel cookie e mantengono tutti i dati di sessione sul server, PrestaShop memorizza una quantità sostanziale di dati direttamente nel cookie stesso. Il cookie del front office contiene campi tra cui l'ID del cliente, il nome e l'email del cliente, se il cliente è connesso, l'ID del carrello, la lingua selezionata, la valuta selezionata, l'ultima categoria visitata, l'ultimo prodotto visitato, il passaggio del checkout e varie altre informazioni di stato.

Questi dati vengono serializzati utilizzando la classe cookie proprietaria di PrestaShop (Cookie.php nella directory classes). Il valore del cookie è crittografato utilizzando una chiave derivata dalla costante _COOKIE_KEY_ in config/settings.inc.php (PrestaShop 1.6/1.7) o app/config/parameters.php (PrestaShop 8.x). Questa crittografia previene la manomissione e protegge i dati sensibili come l'ID del cliente e l'email dall'essere leggibili nel browser.

Perché PrestaShop memorizza i dati nel cookie

La ragione storica di questa scelta progettuale sono le prestazioni. Memorizzando i dati di sessione nel cookie, PrestaShop evita una ricerca di sessione lato server ad ogni richiesta. Non c'è bisogno di leggere da un file di sessione, interrogare un database o connettersi a un server di sessione. I dati arrivano con la richiesta, già disponibili.

Tuttavia, questo approccio presenta svantaggi che diventano più rilevanti man mano che il negozio cresce. La dimensione del cookie aumenta con la quantità di dati memorizzati, e ogni richiesta HTTP (incluse le richieste per immagini, CSS e file JavaScript) invia il cookie completo al server. Un cookie da 4 KB inviato con 30 richieste di risorse per caricamento pagina significa 120 KB di banda di upload non necessaria per caricamento pagina. Questo overhead è misurabile sulle connessioni mobili e su larga scala.

Dimensione del cookie e impatto sulle prestazioni

I cookie del browser hanno un limite pratico di dimensione di circa 4.096 byte per cookie. Il cookie del front office di PrestaShop può avvicinarsi o superare questo limite, soprattutto quando i moduli aggiungono i propri dati al cookie tramite hookActionBeforeSubmitAccount o modificando direttamente l'oggetto cookie.

Misurare l'impatto della dimensione del cookie

Per vedere come i cookie influenzano le prestazioni del tuo negozio, apri gli strumenti per sviluppatori del browser e vai alla scheda Network. Guarda gli header della richiesta per qualsiasi richiesta al tuo dominio. L'header Cookie mostra tutti i cookie inviati. Nota la sua dimensione. Ora guarda gli header della richiesta per una risorsa statica (un'immagine o un file CSS) sullo stesso dominio. Gli stessi cookie vengono inviati anche con quella richiesta, aggiungendo overhead senza motivo.

Ridurre l'overhead dei cookie per le risorse statiche

Il modo più efficace per eliminare l'overhead dei cookie per i file statici è servirli da un dominio diverso (un dominio senza cookie). In PrestaShop, puoi configurare i server multimediali nel back office in Parametri avanzati > Prestazioni. Quando imposti un server multimediale come static.tuodominio.com, PrestaShop serve immagini, CSS e JavaScript da quel dominio. Poiché i cookie sono specifici per dominio, nessun cookie viene inviato con le richieste al dominio multimediale.

In alternativa, un CDN come Cloudflare, Fastly o CloudFront può servire le tue risorse statiche. I server edge CDN tipicamente rimuovono i cookie dalle risposte memorizzate nella cache, quindi anche se i cookie vengono inviati nella richiesta, la risposta proviene dalla cache senza l'overhead di un viaggio di andata e ritorno al server di origine.

Gonfiamento dei cookie da parte dei moduli

I moduli di terze parti talvolta aggiungono dati al cookie di PrestaShop senza considerare le implicazioni sulla dimensione. Ogni modulo che memorizza un valore nel cookie ne aumenta la dimensione e l'overhead su ogni richiesta. Se il tuo cookie è insolitamente grande, verifica quali dati hanno aggiunto i moduli esaminando il contenuto decrittato del cookie o revisionando il codice dei moduli alla ricerca di chiamate a $this->context->cookie->mymodule_value = ....

I moduli ben progettati utilizzano l'archiviazione lato server (database o cache) e memorizzano al massimo un piccolo identificatore nel cookie. I moduli mal progettati scaricano intere strutture dati nel cookie, gonfiandone la dimensione. Se identifichi un modulo problematico, contatta lo sviluppatore o sostituisci l'archiviazione nel cookie con un'archiviazione basata su database utilizzando un identificatore di sessione.

Gestione delle sessioni: file, database e Redis

Mentre PrestaShop memorizza alcuni dati direttamente nei cookie, PHP mantiene anche il proprio sistema di sessioni. Il back office di PrestaShop si affida maggiormente alle sessioni PHP rispetto al front office. Il gestore di sessione determina dove i dati di sessione vengono memorizzati lato server.

Sessioni basate su file (predefinite)

Per impostazione predefinita, PHP memorizza le sessioni come file nella directory session.save_path (tipicamente /tmp o /var/lib/php/sessions). Ogni sessione crea un file. Per un negozio con migliaia di sessioni attive, questo significa migliaia di file piccoli. Le sessioni basate su file funzionano bene per negozi piccoli e medi ma possono causare problemi su larga scala.

I problemi comuni con le sessioni basate su file includono la raccolta rifiuti delle sessioni lenta quando la directory delle sessioni contiene troppi file, il blocco dei file che può causare la serializzazione delle richieste (due richieste dalla stessa sessione non possono essere elaborate simultaneamente) e gli ambienti di hosting condiviso dove la directory delle sessioni si riempie o ha permessi restrittivi.

Sessioni nel database

PrestaShop supporta la memorizzazione delle sessioni nel database. Questo viene configurato nelle impostazioni PHP o attraverso il gestore di sessioni di PrestaShop. Le sessioni nel database eliminano i problemi del file system ma aggiungono una query al database per ogni richiesta. Per i negozi che hanno già un carico elevato sul database, questo può peggiorare le prestazioni. Tuttavia, le sessioni nel database hanno il vantaggio di essere condivise tra più server web in una configurazione con bilanciamento del carico.

Sessioni con Redis o Memcached

Per i negozi PrestaShop ad alto traffico, Redis è il backend ottimale per l'archiviazione delle sessioni. Redis memorizza i dati di sessione in memoria, fornendo tempi di accesso inferiori al millisecondo. Supporta la scadenza automatica (timeout di sessione) e i dati di sessione sono condivisi tra tutte le istanze del server web.

Per configurare PHP per utilizzare Redis per le sessioni, imposta session.save_handler = redis e session.save_path = "tcp://127.0.0.1:6379" nel tuo file php.ini o nella configurazione del pool PHP-FPM. Se la tua istanza Redis richiede autenticazione, aggiungi la password al percorso di salvataggio: "tcp://127.0.0.1:6379?auth=tuapassword".

PrestaShop supporta già Redis per il caching degli oggetti (configurato nel back office in Parametri avanzati > Prestazioni). Utilizzare la stessa istanza Redis sia per le sessioni che per il caching degli oggetti semplifica la tua infrastruttura fornendo al contempo eccellenti prestazioni per entrambi.

Attributi SameSite, Secure e HttpOnly

I browser moderni applicano attributi di sicurezza dei cookie che influenzano direttamente il comportamento dei cookie di PrestaShop. Attributi cookie configurati in modo errato causano errori di login, carrelli persi e errori nell'elaborazione dei pagamenti.

Attributo SameSite

L'attributo SameSite controlla se un cookie viene inviato con richieste cross-site. Ha tre valori possibili:

SameSite=Strict significa che il cookie non viene mai inviato con richieste cross-site. Questo è troppo restrittivo per PrestaShop perché i clienti che cliccano un link al tuo negozio da un'email o dai social media non avrebbero il cookie di sessione inviato, effettivamente disconnettendoli.

SameSite=Lax è il valore predefinito nei browser moderni. Il cookie viene inviato con le navigazioni di primo livello (clic su un link) ma non con le sotto-richieste cross-site (immagini, iframe, AJAX). Questo funziona bene per il cookie del front office di PrestaShop nella maggior parte dei casi.

SameSite=None significa che il cookie viene sempre inviato, incluse le richieste cross-site. Deve essere abbinato all'attributo Secure. È necessario quando il tuo negozio è incorporato in un iframe su un altro sito o quando i gateway di pagamento di terze parti devono reindirizzare al tuo negozio con la sessione intatta.

Problemi con i gateway di pagamento

Molti problemi di pagamento in PrestaShop sono causati da problemi con i cookie SameSite. Lo scenario tipico è: un cliente procede al checkout, viene reindirizzato al sito del gateway di pagamento, completa il pagamento e viene reindirizzato al tuo negozio. Se il cookie di sessione ha SameSite=Lax, potrebbe non essere inviato al reindirizzamento dal gateway di pagamento, a seconda di come viene implementato il reindirizzamento. Se il gateway utilizza un reindirizzamento POST (comune con 3D Secure), la politica Lax blocca il cookie e PrestaShop perde la sessione. Il cliente vede un carrello vuoto o una pagina di errore generica invece della conferma dell'ordine.

La soluzione è impostare il cookie di PrestaShop su SameSite=None; Secure. In PrestaShop 1.7.7+ e 8.x, questo può essere configurato nelle impostazioni dei cookie. Per le versioni precedenti, potrebbe essere necessario modificare la classe Cookie o aggiungere header tramite la configurazione del server web. Testa sempre i flussi di pagamento dopo aver modificato le impostazioni SameSite.

Attributo Secure

L'attributo Secure assicura che il cookie venga inviato solo su connessioni HTTPS. Se il tuo negozio funziona su HTTPS (come dovrebbe), questo attributo impedisce che il cookie venga trasmesso su una connessione non crittografata, proteggendolo dall'intercettazione. PrestaShop imposta questo attributo quando il negozio rileva una connessione HTTPS.

Un problema comune si verifica con configurazioni miste HTTP/HTTPS. Se il back office è su HTTPS ma alcune pagine del front office sono su HTTP, i cookie contrassegnati come Secure non verranno inviati sulle pagine HTTP, interrompendo la sessione. La soluzione è forzare HTTPS ovunque, cosa che dovresti fare comunque per ragioni di sicurezza e SEO.

Attributo HttpOnly

L'attributo HttpOnly impedisce a JavaScript di accedere al cookie tramite document.cookie. Questa è una misura di sicurezza critica contro gli attacchi cross-site scripting (XSS). Se un attaccante inietta JavaScript malevolo nel tuo negozio (attraverso un modulo vulnerabile, per esempio), l'attributo HttpOnly impedisce a quel codice di rubare i cookie di sessione.

PrestaShop imposta il flag HttpOnly sui suoi cookie per impostazione predefinita. Non disabilitarlo a meno che tu non abbia una ragione molto specifica e comprenda le implicazioni di sicurezza.

Debug dei problemi di sessione e cookie

I problemi di cookie e sessione si manifestano come sintomi misteriosi: clienti disconnessi in modo casuale, carrelli che si svuotano da soli, sessioni di amministrazione che scadono immediatamente, processi di checkout che falliscono silenziosamente. Il debug sistematico richiede il controllo di diversi livelli.

Strumenti per sviluppatori del browser

Apri la scheda Application (Chrome) o Storage (Firefox) e vai a Cookie. Trova il dominio del tuo negozio ed esamina tutti i cookie. Controlla le colonne Nome, Valore, Dominio, Percorso, Scadenza, Dimensione, HttpOnly, Secure e SameSite. Cerca cookie insolitamente grandi, con impostazioni di dominio errate (un cookie per www.example.com non verrà inviato a example.com) o privi di attributi di sicurezza.

Verifica delle sessioni lato server

Se le sessioni sono memorizzate in file, controlla la directory delle sessioni per la presenza e l'età dei file di sessione. Se un cliente segnala di essere stato disconnesso, trova il suo file di sessione (il nome del file è l'ID di sessione dal cookie PHPSESSID) e controlla quando è stato modificato l'ultima volta. Se il file manca, la sessione è stata raccolta dal garbage collector o non è mai stata creata correttamente.

Per le sessioni Redis, usa redis-cli per verificare se la chiave di sessione esiste: EXISTS PHPREDIS_SESSION:session_id. Controlla il TTL per vedere se sta per scadere: TTL PHPREDIS_SESSION:session_id.

Cause comuni delle disconnessioni casuali

Il _COOKIE_KEY_ è cambiato. Se questa chiave cambia (durante un deployment configurato male, una sovrascrittura del file delle impostazioni o un aggiornamento), tutti i cookie esistenti diventano illeggibili perché erano crittografati con la vecchia chiave. Ogni cliente viene effettivamente disconnesso. La soluzione è ripristinare la chiave originale da un backup.

La raccolta rifiuti delle sessioni è troppo aggressiva. Il parametro PHP session.gc_maxlifetime determina per quanto tempo (in secondi) un file di sessione è considerato valido. Se questo è impostato troppo basso (il valore predefinito è 1440 secondi, ovvero 24 minuti), le sessioni dei clienti che navigano lentamente vengono eliminate. Per un negozio, impostalo ad almeno 3600 (1 ora) o superiore.

Bilanciatore di carico senza affinità di sessione. Se il tuo negozio funziona su più server web dietro un bilanciatore di carico e le sessioni sono memorizzate in file, ogni server ha la propria directory di sessione. Un cliente le cui richieste alternano tra server perderà la sessione ad ogni cambio. La soluzione è l'affinità di sessione (sticky session) sul bilanciatore di carico, o l'archiviazione condivisa delle sessioni utilizzando Redis o un database.

Disallineamento del dominio del cookie. Se il tuo negozio è accessibile sia su www.example.com che su example.com, ma il dominio del cookie è impostato su www.example.com, i clienti che accedono al sito senza il prefisso www non avranno il cookie. Assicura un utilizzo coerente del dominio con un reindirizzamento e verifica il dominio del cookie nelle impostazioni di PrestaShop.

Conformità dei cookie al GDPR

Il Regolamento generale sulla protezione dei dati (GDPR) e la Direttiva ePrivacy richiedono il consenso informato prima di impostare cookie non essenziali nel browser dell'utente. I negozi PrestaShop devono conformarsi a queste normative, e il mancato rispetto può comportare sanzioni significative.

Cookie essenziali vs non essenziali

Il GDPR distingue tra cookie strettamente necessari per il funzionamento del sito web e cookie che servono ad altri scopi come analisi, marketing o personalizzazione. Il cookie di sessione di PrestaShop è essenziale perché il negozio non può funzionare senza. Un cliente non può aggiungere prodotti al carrello né completare un acquisto senza un cookie di sessione. I cookie essenziali non richiedono il consenso ai sensi del GDPR.

Tuttavia, molti altri cookie comunemente presenti nei negozi PrestaShop sono non essenziali e richiedono un consenso esplicito prima di essere impostati. Questi includono i cookie di tracciamento di Google Analytics (_ga, _gid), i cookie del Facebook Pixel, i cookie pubblicitari delle piattaforme di remarketing, i cookie dei widget di chat dal vivo, i cookie dei pulsanti di condivisione sui social media e qualsiasi cookie impostato da moduli di terze parti per scopi di tracciamento o personalizzazione.

Implementazione del consenso ai cookie

PrestaShop non include un meccanismo integrato di consenso ai cookie che soddisfi i requisiti del GDPR. Hai bisogno di un modulo PrestaShop progettato per il consenso ai cookie o dell'integrazione con una piattaforma di gestione del consenso (CMP) di terze parti come Cookiebot, Osano o Usercentrics.

Un'implementazione corretta del consenso ai cookie deve presentare all'utente una scelta chiara prima che qualsiasi cookie non essenziale venga impostato. Deve consentire all'utente di accettare o rifiutare categorie individuali di cookie (analisi, marketing, ecc.), non solo offrire una scelta tutto-o-niente. Deve ricordare la scelta dell'utente e non chiedere di nuovo fino alla scadenza del consenso. Deve effettivamente impedire l'impostazione dei cookie bloccati, non solo registrare la preferenza continuando a caricare i codici di tracciamento.

L'ultimo punto è critico e spesso gestito male. Un banner di consenso che appare ma carica comunque Google Analytics indipendentemente dalla scelta dell'utente non fornisce alcuna protezione legale. L'implementazione deve caricare condizionalmente le risorse di tracciamento e marketing in base al consenso dell'utente.

Implementazione tecnica del consenso

L'approccio tecnico alla gestione dei cookie basata sul consenso prevede l'avvolgimento del codice non essenziale in controlli del consenso. Per il JavaScript inline che imposta cookie o carica pixel di tracciamento, sostituisci l'esecuzione diretta con un caricatore condizionato dal consenso. Il codice di tracciamento viene memorizzato ma non eseguito fino a quando l'utente non dà il consenso.

Per i moduli di terze parti che impostano cookie, l'implementazione è più complessa. Alcuni moduli forniscono hook o opzioni di configurazione per l'integrazione del consenso. Altri caricano i loro cookie incondizionatamente e devono essere modificati o sostituiti. Controlla ogni modulo nel tuo negozio per l'utilizzo dei cookie e determina quali impostano cookie non essenziali.

Consenso ai cookie e caching

Il caching a pagina intera crea un conflitto con il consenso ai cookie. Se una pagina viene memorizzata nella cache con Google Analytics caricato e servita a un utente che non ha dato il consenso, stai violando il GDPR. Ci sono due approcci per gestire questo.

Il primo approccio consiste nel memorizzare nella cache la pagina senza risorse non essenziali e iniettarle dinamicamente tramite JavaScript dopo aver verificato il consenso. Questo funziona bene con il sistema CCC (Combine, Compress, Cache) di PrestaShop e con Varnish o altre cache reverse proxy.

Il secondo approccio consiste nel non memorizzare nella cache le pagine per gli utenti che non hanno ancora fatto una scelta di consenso (visitatori per la prima volta). Questo peggiora le prestazioni per i nuovi visitatori ma garantisce la conformità. La maggior parte delle piattaforme di gestione del consenso utilizza il primo approccio perché preserva i benefici del caching.

Considerazioni di sicurezza relative ai cookie

Oltre agli attributi HttpOnly e Secure già discussi, ci sono ulteriori considerazioni di sicurezza per i cookie di PrestaShop.

Furto di cookie e dirottamento della sessione

Se un attaccante ottiene un cookie di sessione PrestaShop valido, può impersonare il cliente o l'amministratore. La protezione principale è HTTPS ovunque (previene l'intercettazione), cookie HttpOnly (previene il furto tramite XSS) e l'attributo Secure (previene la trasmissione su HTTP). PrestaShop in alcune configurazioni lega anche le sessioni agli indirizzi IP, il che fornisce un ulteriore livello di protezione ma può causare problemi agli utenti il cui indirizzo IP cambia (utenti mobili, utenti VPN).

Sicurezza della chiave del cookie

Il _COOKIE_KEY_ nella configurazione di PrestaShop è la chiave principale per la crittografia dei cookie. Se questa chiave viene compromessa, un attaccante può decrittare qualsiasi cookie di PrestaShop e falsificare cookie di sessione validi. Proteggi questa chiave limitando l'accesso ai file di configurazione, non committandola mai in repository pubblici e non condividendola mai nelle richieste di supporto.

Prevenzione del fissaggio della sessione

Gli attacchi di fissaggio della sessione prevedono che un attaccante imposti un ID di sessione noto nel browser della vittima prima che questa effettui il login. Quando la vittima effettua il login, l'ID di sessione pre-impostato dall'attaccante diventa autenticato. PrestaShop mitiga questo rigenerando l'ID di sessione al login. Assicurati che la rigenerazione dell'ID di sessione funzioni correttamente e non sia stata disabilitata da alcun modulo o modifica di configurazione.

Risoluzione dei problemi comuni con i cookie

Loop di login nel pannello di amministrazione

Il sintomo è inserire credenziali valide nel back office di PrestaShop, vedere brevemente la dashboard ed essere reindirizzati alla pagina di login. Questo è quasi sempre un problema di cookie. Verifica che il dominio del cookie sia corretto, che il nome della directory di amministrazione non sia cambiato, che HTTPS sia configurato correttamente (il contenuto misto può impedire l'invio del cookie Secure) e che la directory di archiviazione delle sessioni sia scrivibile dal server web.

Carrello che si svuota durante la navigazione

Se il carrello si svuota quando il cliente naviga verso un'altra pagina, il cookie di sessione non viene mantenuto. Le cause comuni includono un'impostazione del dominio del cookie mancante o errata, un session.cookie_lifetime configurato male in PHP (impostato a 0 significa che il cookie scade alla chiusura del browser, il che è corretto, ma alcune configurazioni lo impostano a un tempo molto breve), o un livello CDN o di caching che rimuove l'header Set-Cookie dalle risposte.

Fallimento del checkout dopo il pagamento

Quando i clienti completano il pagamento ma vedono un errore o un carrello vuoto al ritorno al tuo negozio, la politica SameSite del cookie è solitamente la causa, come descritto nella sezione sui gateway di pagamento sopra. Testa l'intero flusso di checkout con gli strumenti per sviluppatori del browser aperti, osservando i cookie in ogni passaggio per identificare dove la sessione viene persa.

Più negozi sullo stesso dominio

Se gestisci più installazioni PrestaShop sullo stesso dominio (per esempio in sottodirectory), i loro cookie possono entrare in conflitto. Ogni installazione utilizza un nome di cookie simile, e se il percorso del cookie è impostato su /, il cookie di un negozio sovrascrive quello dell'altro. Imposta nomi di cookie unici per ogni installazione attraverso il _COOKIE_KEY_ (che influisce sul nome del cookie) o configura il percorso del cookie per corrispondere alla sottodirectory di ogni installazione.

Ottimizzazione della configurazione dei cookie per le prestazioni

Una configurazione dei cookie di PrestaShop ben ottimizzata minimizza l'overhead mantenendo la funzionalità. Utilizza un dominio senza cookie o un CDN per le risorse statiche per evitare di inviare cookie con le richieste di immagini, CSS e JavaScript. Mantieni la dimensione del cookie piccola impedendo ai moduli di memorizzare dati non necessari. Imposta timeout di sessione appropriati che bilancino la sicurezza (più breve è più sicuro) con l'esperienza utente (più lungo significa meno ri-login). Usa Redis per l'archiviazione delle sessioni per combinare accesso veloce con stato condiviso tra le istanze del server. Abilita gli attributi Secure e HttpOnly per proteggere l'integrità del cookie senza influire sulle prestazioni. Implementa un consenso ai cookie adeguato per evitare di caricare cookie di tracciamento non necessari che aggiungono overhead e rischio legale.

Ognuna di queste ottimizzazioni è individualmente piccola, ma insieme creano un miglioramento significativo sia nelle prestazioni che nella conformità. La gestione dei cookie non è un lavoro affascinante, ma è alla base di ogni interazione tra il tuo negozio e i tuoi clienti, il che lo rende degno di essere fatto bene.

Leggi la risposta completa

Why Database Performance Matters in PrestaShop

PrestaShop is a database-heavy application. Every product page, category listing, search result, cart update, and checkout step involves multiple database queries. A typical product page can generate 50 to 200 or more SQL queries depending on the number of modules installed, the complexity of the product (combinations, features, attachments), and the theme. When any of these queries run slowly, the entire page slows down, and the effect compounds under load.

The challenge is identifying which queries are actually slow. With hundreds of queries per page load, you cannot simply guess. You need data. The MySQL slow query log is the most direct and reliable tool for collecting this data. It records every query that exceeds a time threshold you define, giving you a clear picture of where your database spends the most time.

This guide covers how to enable and configure the slow query log, how to analyze the results, how to interpret query execution plans, and how to apply the most common optimizations for PrestaShop databases.

Enabling the Slow Query Log

The slow query log is a MySQL feature that writes queries exceeding a specified execution time to a log file. It is disabled by default on most installations because it adds a small amount of I/O overhead, but the performance cost is negligible compared to the diagnostic value it provides.

Configuration via my.cnf

To enable the slow query log permanently, add the following lines to your MySQL configuration file. On most Linux systems, this file is located at /etc/mysql/my.cnf, /etc/my.cnf, or in a directory like /etc/mysql/conf.d/:

slow_query_log = 1 enables the feature.

slow_query_log_file = /var/log/mysql/slow-query.log specifies where the log is written. Make sure the MySQL process has write permissions to this directory.

long_query_time = 1 sets the threshold in seconds. Any query that takes longer than this value is logged. Start with 1 second to catch the most egregious offenders, then lower it to 0.5 or even 0.1 seconds as you optimize the worst queries and want to find more subtle bottlenecks.

log_queries_not_using_indexes = 1 logs queries that do not use any index, regardless of how long they take. This is extremely useful for PrestaShop because many performance problems are caused by full table scans on large tables. However, this can generate a lot of log entries on a busy store, so you may want to enable it temporarily during analysis and disable it afterward.

After editing the configuration file, restart MySQL for the changes to take effect.

Enabling at Runtime

You can also enable the slow query log without restarting MySQL by running SQL commands. Connect to MySQL as root and execute:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL log_queries_not_using_indexes = 1;

Runtime changes take effect immediately but do not persist across MySQL restarts. This approach is useful for temporary analysis sessions where you want to collect data for a specific period and then disable logging.

Choosing the Right Threshold

The long_query_time value determines what gets logged. Setting it too high means you miss moderately slow queries that collectively impact performance. Setting it too low floods the log with entries that are not individually problematic.

For an initial analysis, start at 1 second. This catches queries that are clearly too slow. After optimizing those, lower the threshold to 0.5 seconds, then 0.2 seconds. On a well-optimized PrestaShop database, the goal is for no query to take longer than 0.1 seconds, but reaching that level requires significant optimization work.

Keep in mind that query execution time varies with server load. A query that takes 0.3 seconds under normal load might take 2 seconds during a traffic spike because of CPU contention, disk I/O bottlenecks, or lock contention. The slow query log captures actual execution times, so analyzing logs from peak traffic periods gives you the most realistic picture.

Analyzing the Slow Query Log

The raw slow query log is a text file with entries that look like this:

# Time: 2024-03-15T14:22:33.456789Z
# User@Host: prestashop[prestashop] @ localhost []
# Query_time: 3.456123 Lock_time: 0.000234 Rows_sent: 1 Rows_examined: 847293
SET timestamp=1710511353;
SELECT * FROM ps_product WHERE active = 1 AND id_product NOT IN (SELECT id_product FROM ps_category_product WHERE id_category = 2);

The key fields are Query_time (how long the query took), Lock_time (how long it waited for a lock), Rows_sent (how many rows were returned), and Rows_examined (how many rows MySQL had to look at to find the result). A query that examines 847,293 rows to return 1 row is a clear sign of a missing index or inefficient query structure.

Using mysqldumpslow

Reading the raw log file is impractical for busy stores that generate thousands of slow query entries. The mysqldumpslow tool, included with MySQL, aggregates and summarizes slow query log entries. It groups identical queries together (abstracting away specific values) and sorts them by various criteria.

To find the 10 slowest queries by average time: mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

To find the queries with the most total execution time: mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

To find the queries that examined the most rows: mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

The -s flag specifies the sort order: at for average time, t for total time, c for count (how many times the query appeared), r for rows examined. The -t flag limits the output to the top N queries.

The most useful sort for initial analysis is by total time (-s t), which shows you which queries consume the most database time overall. A query that takes 0.5 seconds but runs 1000 times per hour consumes more total time than a query that takes 5 seconds but runs once per hour.

Using pt-query-digest

For more detailed analysis, Percona Toolkit's pt-query-digest is the industry standard tool. It provides far more detailed statistics than mysqldumpslow, including percentile distributions of query times, variance analysis, and table-level statistics.

Basic usage: pt-query-digest /var/log/mysql/slow-query.log

The output starts with a profile section that ranks queries by total time, similar to mysqldumpslow but with more detail. Each query then gets a detailed section showing the minimum, maximum, mean, median, and 95th percentile execution times, plus the distribution of rows examined and rows sent.

The 95th percentile is particularly important for PrestaShop performance. It tells you the execution time that 95% of executions fall below. If the average is 0.3 seconds but the 95th percentile is 2.5 seconds, you have a consistency problem: most of the time the query is acceptable, but 5% of users experience a much slower response.

You can install Percona Toolkit on Debian and Ubuntu with apt install percona-toolkit or download it from the Percona website. It is worth installing on any server where you run PrestaShop.

Common Slow Queries in PrestaShop

Certain query patterns appear repeatedly in PrestaShop slow query logs. Knowing these patterns helps you diagnose issues faster.

Full Table Scans on ps_product

Queries against the ps_product table without proper index usage are among the most common slow queries. As your catalog grows beyond a few thousand products, any query that scans the entire product table becomes problematic. Look for queries with WHERE clauses on columns that are not indexed, or queries that join ps_product with ps_product_lang and ps_product_shop without using the primary keys efficiently.

Category Product Listings with Many Filters

When customers use layered navigation (faceted search) to filter products by attributes, features, or price ranges, PrestaShop generates complex queries that join multiple tables. The ps_layered_* tables used by the faceted search module can become performance bottlenecks if indexes are missing or if the indexing process has not run recently.

Search Queries

PrestaShop's built-in search uses the ps_search_word and ps_search_index tables. On stores with large catalogs and many search terms, these tables grow large and queries against them slow down. The search query typically involves a full-text operation or multiple LIKE conditions, both of which are inherently slower than index lookups.

Cart and Order Queries

Queries that aggregate cart or order data can be slow on stores with a long history. If your ps_cart table has millions of rows (which is common because PrestaShop creates a new cart for almost every visitor), queries that scan this table become slow. The same applies to ps_orders and ps_order_detail on high-volume stores.

Statistics and Reporting Queries

Back office statistics modules often run aggregate queries (SUM, COUNT, GROUP BY) across large tables like ps_orders, ps_connections, and ps_page_viewed. These queries can be extremely slow because they scan large datasets. On stores that have been running for years, these tables may contain millions of rows, and statistics queries that worked fine on a small dataset now take minutes.

Module-Generated Queries

Third-party modules frequently generate inefficient queries because module developers often test against small datasets. A module that works perfectly with 100 products may generate catastrophically slow queries with 10,000 products. The slow query log helps you identify which modules are responsible because the query text often includes table names or patterns that point to specific modules.

Using EXPLAIN to Analyze Queries

Once you have identified slow queries from the log, the next step is understanding why they are slow. The EXPLAIN statement shows you how MySQL plans to execute a query, including which indexes it uses, how many rows it expects to examine, and what join strategies it employs.

Reading EXPLAIN Output

Run EXPLAIN followed by the slow query. The output shows one row per table in the query, with these important columns:

type: How MySQL accesses the table. Values from best to worst: system/const (single row, essentially free), eq_ref (one row per join, using unique index), ref (multiple rows, using non-unique index), range (index range scan), index (full index scan), ALL (full table scan). If you see ALL on a table with more than a few thousand rows, that is almost certainly your bottleneck.

key: Which index MySQL actually chose for this table. If this is NULL, no index is being used, and MySQL is scanning the entire table.

rows: The estimated number of rows MySQL needs to examine. This is an estimate, not exact, but it gives you a sense of scale. If the estimated rows value is close to the total number of rows in the table, you have a full table scan.

Extra: Additional information about the execution plan. Watch for Using filesort (MySQL must sort results without an index, which is slow for large datasets), Using temporary (MySQL creates a temporary table, often for GROUP BY or DISTINCT operations), and Using where (MySQL is filtering rows after reading them, which means the index does not fully cover the WHERE clause).

EXPLAIN Example

Consider a slow query: SELECT p.id_product, pl.name FROM ps_product p LEFT JOIN ps_product_lang pl ON p.id_product = pl.id_product WHERE pl.id_lang = 1 AND p.active = 1 AND p.price > 100 ORDER BY p.date_add DESC LIMIT 20

Running EXPLAIN on this query might show that the ps_product table is accessed with type ALL (full table scan), no key is used, and the Extra column shows Using where; Using filesort. This tells you that MySQL is reading every row in the product table, filtering by active status and price, and then sorting the results by date. On a table with 50,000 products, this involves reading and sorting thousands of rows to return just 20.

The fix would be creating a composite index on (active, price, date_add) or restructuring the query to take better advantage of existing indexes.

Index Optimization for PrestaShop

Adding the right indexes is the most effective way to speed up slow queries. An index allows MySQL to find rows without scanning the entire table, similar to how a book's index lets you find a topic without reading every page.

When to Add an Index

Add an index when EXPLAIN shows a full table scan (type ALL) on a table with many rows, when a query runs frequently and consistently appears in the slow query log, and when the query's WHERE clause, JOIN condition, or ORDER BY clause references columns that are not currently indexed.

Do not add indexes blindly. Every index speeds up reads but slows down writes (INSERT, UPDATE, DELETE) because MySQL must update the index on every data modification. PrestaShop performs many writes (cart updates, order creation, statistics tracking), so excessive indexing creates its own performance problems.

Composite Indexes

For PrestaShop queries, composite (multi-column) indexes are often more effective than single-column indexes. A composite index on (id_shop, id_lang, active) lets MySQL efficiently handle queries that filter by all three columns. The order of columns in the index matters: MySQL uses the index from left to right, so the most selective column (the one that filters out the most rows) should generally come first.

PrestaShop's multishop and multilanguage architecture means many queries include id_shop and id_lang conditions. These columns appear in virtually every query against product, category, and CMS tables. If you are adding custom indexes, including these columns is often necessary for the index to be useful.

Covering Indexes

A covering index contains all the columns that a query needs, so MySQL can satisfy the entire query from the index without reading the actual table data. This is shown in EXPLAIN as Using index in the Extra column. Covering indexes provide the best possible performance because reading from an index is faster than reading from the table itself (indexes are smaller and more likely to fit in memory).

Common Index Additions for PrestaShop

Several indexes that are not present in a default PrestaShop installation can significantly improve performance on large stores. These include indexes on the date_add column in ps_cart and ps_orders for queries that filter or sort by date, composite indexes on ps_product_attribute for combination-heavy queries, and indexes on custom columns added by modules that run frequent queries against them.

Before adding any index, verify the improvement by running the slow query with and without the index. Use EXPLAIN to confirm that MySQL actually uses the new index. An unused index wastes disk space and slows down writes without providing any benefit.

Connection Management and Query Optimization

Connection Pooling

PrestaShop uses a single database connection per request by default. Each PHP process opens a connection to MySQL, executes its queries, and closes the connection when the request completes. On busy stores with many concurrent visitors, this creates a high rate of connection creation and teardown, which has overhead.

MySQL's max_connections setting limits how many simultaneous connections are allowed. If your store runs out of connections, visitors see "Too many connections" errors. The default value is often 151, which may be insufficient for high-traffic stores running many PHP-FPM workers.

To determine the right value, check the Max_used_connections status variable, which tells you the peak number of simultaneous connections since MySQL started. Set max_connections to at least 20% above this peak to provide headroom during traffic spikes.

Query Optimization Techniques

Beyond indexing, several query-level optimizations can improve PrestaShop database performance:

Avoid SELECT *: Queries that select all columns transfer more data than necessary between MySQL and PHP. PrestaShop core sometimes uses SELECT * for convenience, but custom queries should specify only the columns needed.

Limit subqueries: MySQL's optimizer handles subqueries less efficiently than JOINs in many cases. If you see slow queries with IN (SELECT ...) patterns, rewriting them as JOINs often improves performance. This applies particularly to queries generated by modules.

Use LIMIT wisely: For paginated listings, PrestaShop typically uses LIMIT offset, count. For large offsets (like page 500 of a product listing), this becomes slow because MySQL must read and discard all rows up to the offset. A more efficient approach is keyset pagination, where you filter by the last seen ID instead of using an offset.

Batch operations: Modules that process products in loops often execute one query per product. Rewriting these as batch queries (using IN clauses or CASE statements for updates) dramatically reduces the number of round trips to the database.

Monitoring and Ongoing Optimization

Database optimization is not a one-time task. As your catalog grows, traffic patterns change, and you install new modules, new slow queries emerge. Establish a routine for monitoring database performance.

Enable the slow query log permanently with a reasonable threshold (0.5 to 1 second). Review the log weekly or monthly using pt-query-digest. Pay attention to new queries that appear in the log and to existing queries whose execution time increases over time.

Monitor MySQL's key performance metrics: the buffer pool hit rate (should be above 99%), the number of slow queries per hour, the average query time, and the connection usage. These metrics give you early warning of performance degradation before it impacts users.

When you add or update modules, check whether they introduce new slow queries. Run the module's functionality while monitoring the slow query log to catch problems before they affect production traffic. A module that generates efficient queries on a test store with 50 products may create severe bottlenecks on a production store with 50,000 products. Testing with production-scale data is the only reliable way to verify module performance.

Summary

The MySQL slow query log is your most valuable tool for finding and fixing database bottlenecks in PrestaShop. Enable it, set an appropriate threshold, and use analysis tools like mysqldumpslow or pt-query-digest to identify the worst offenders. Use EXPLAIN to understand why specific queries are slow, and apply targeted indexes to eliminate full table scans. Monitor your database performance continuously, because optimization is an ongoing process as your store grows. The combination of slow query log analysis, EXPLAIN-driven optimization, and proper indexing can transform a sluggish PrestaShop store into one that handles large catalogs and high traffic with responsive page loads.

Leggi la risposta completa

Quando le combinazioni PrestaShop uccidono le prestazioni: limiti e soluzioni

Il sistema di combinazioni di PrestaShop permette di creare varianti di prodotto. Funziona perfettamente per prodotti con poche varianti. Ma quando i prodotti hanno centinaia o migliaia di combinazioni, le prestazioni degradano drasticamente.

Perche le combinazioni causano problemi di prestazioni

Architettura del database

PrestaShop memorizza i dati delle combinazioni in piu tabelle: ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Un prodotto con 5 taglie e 10 colori crea 50 combinazioni con oltre 350 righe nel database.

Il problema della crescita esponenziale

Attributi	Valori	Combinazioni	Righe DB
2	5 x 5	25	~175
3	10 x 15 x 8	1.200	~8.400
4	10 x 15 x 8 x 5	6.000	~42.000

Limiti pratici

Numero	Front Office	Back Office	Verdetto
1-50	Veloce	Veloce	Nessun problema
50-200	Accettabile	Accettabile	Gestibile
200-500	Lento (3-8s)	Lento	Ottimizzazione necessaria
500-1000	Molto lento	Molto lento	Considerare ristrutturazione
1000+	Inutilizzabile	Spesso crash	Ristrutturazione necessaria

Soluzione 1 - Ristrutturare il catalogo

Invece di un prodotto con 50 combinazioni, creare prodotti separati per colore con 5 combinazioni ciascuno.

Soluzione 2 - Ottimizzazione database e server

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Soluzione 3 - Lazy loading delle combinazioni

Invece di caricare tutte le combinazioni al caricamento della pagina, recuperare i dati via AJAX quando il cliente seleziona un attributo.

Soluzione 4 - Strategie di caching

Cache dell'intera pagina (Varnish, LiteSpeed) per le pagine prodotto. Redis o Memcached per il cache degli oggetti.

Quando evitare completamente le combinazioni

Prodotti configurabili con 4+ attributi - Modulo configuratore prodotto
Prodotti dimensionali - Modulo dimensioni personalizzate
Prodotti print-on-demand - Modulo designer prodotto

Raccomandazioni per numero di combinazioni

Numero	Azione raccomandata
Sotto 100	Nessuna azione necessaria
100-300	Indici DB, OPcache, Redis
300-1000	Dividere prodotti, indici, lazy loading
Oltre 1000	Ristrutturare catalogo, modulo configuratore

Leggi la risposta completa

Cookie	Fornitore	Finalità	Durata
PrestaShop-*	PrestaShop	Gestione della sessione e funzionalità del carrello	Sessione
PHPSESSID	PHP	Identificativo sessione PHP	Sessione
mprcr_consent	MPR Cookies Revolution	Memorizza le preferenze di consenso dei cookie	365 giorno/i
mprcr_version	MPR Cookies Revolution	Traccia la versione della configurazione del consenso	365 giorno/i

Cookie	Fornitore	Finalità	Durata
TawkConnectionTime	Tawk.to	Czas polaczenia sesji czatu	Sessione
__tawkuuid	Tawk.to	Identyfikuje powracajacych uzytkownikow czatu	6 mese/i