Schermata bianca su PrestaShop: come trovare l'errore VERO in 15 minuti

Schermata bianca su PrestaShop: trova l’errore vero in 15 minuti

Che cosa facciamo quando il sito diventa bianco?

Non reinstalliamo PrestaShop. Non aggiorniamo cinque moduli insieme. Non cambiamo PHP perché “forse è quello”. La schermata bianca PrestaShop non è il problema vero: è il sintomo. Il problema vero è scritto quasi sempre in un log.

Il cliente non compra, il checkout magari non si apre, il back office resta vuoto. È come avere il registratore di cassa spento in negozio: il cliente vede solo che non può pagare. Lei invece deve capire se manca corrente, se è rotto il POS o se il gestionale è bloccato.

Il discorso qual è? In emergenza bisogna restringere il campo. Ogni modifica fatta a caso aggiunge rumore. Dopo, trovare la causa richiede più tempo e costa di più.

Perché compare la schermata bianca PrestaShop?

La schermata bianca PrestaShop compare quando un errore grave blocca PHP prima che il sito mostri una pagina leggibile. In produzione l’errore viene spesso nascosto, quindi lei vede bianco ma il server ha già registrato un messaggio tecnico.

Una prestashop pagina bianca può colpire homepage, back office, checkout, pagina prodotto o una singola categoria. A volte invece vede un errore 500 PrestaShop. Operativamente cambia poco: il server non riesce a completare la richiesta.

Quali sono le cause più frequenti?

Le cause più comuni sono tracciabili. Un modulo incompatibile PrestaShop, un override vecchio, un tema non aggiornato o una versione PHP sbagliata possono bloccare tutto.

Altre volte il problema è un memory limit PrestaShop troppo basso. Succede durante import catalogo, rigenerazione immagini, esportazioni feed, statistiche pesanti o checkout con molte regole carrello.

• Modulo aggiornato male o non compatibile.
• Override PHP rotto o duplicato.
• Tema non compatibile con la versione installata.
• Versione PHP non allineata a PrestaShop e moduli.
• Cache corrotta.
• Permessi file errati.
• File mancanti dopo deploy o aggiornamento.
• PrestaShop schermata bianca dopo aggiornamento modulo.

Cosa fare nei primi 15 minuti quando compare la schermata bianca?

Nei primi 15 minuti non deve disattivare tutto a caso. Deve segnare cosa è successo, attivare il debug, leggere i log e capire quale file, modulo o processo ha causato la schermata bianca PrestaShop.

Non ti dico che in 15 minuti risolvi sempre. Ti dico che in 15 minuti puoi smettere di indovinare.

Minuto 0-3: cosa non deve toccare subito?

Che cosa facciamo? Prima fermiamo il danno.

Non svuoti cartelle a caso. Non aggiorni altri moduli. Non cambi versione PHP tre volte. Senza offesa: non è un problema di intelligenza, è un problema di costo. Ogni tentativo non documentato può aggiungere mezz’ora di diagnosi.

Prima annoti:

• ora esatta in cui è comparsa la schermata bianca;
• pagina colpita: homepage, prodotto, checkout o back office;
• ultima modifica fatta;
• modulo installato o aggiornato;
• versione PrestaShop;
• versione PHP;
• screenshot dell’errore, se visibile.

Noi siamo pessimisti, perché in emergenza conviene esserlo. Se le campagne stanno mandando traffico al checkout bianco, anche pochi minuti possono diventare ordini persi.

Se queste situazioni capitano spesso, serve anche una procedura di backup PrestaShop. Meglio fatto che perfetto, ma non alla cieca su un negozio che vende.

Minuto 3-7: come si attiva la modalità debug?

La modalità debug serve a far parlare PrestaShop. La costante da cercare è _PS_MODE_DEV_, di solito nel file:

/config/defines.inc.php

Trovi questa riga:

define('_PS_MODE_DEV_', false);

Durante la diagnosi la modifichi così:

define('_PS_MODE_DEV_', true);

Questo è il passaggio base per trovare errore vero schermata bianca PrestaShop. Attenzione però: ps_mode_dev PrestaShop va usato temporaneamente. Non deve restare attivo in produzione.

Formula pratica: attiva, ricarica la pagina bianca, copia l’errore, fai screenshot, disattiva.

Minuto 7-12: come leggere il messaggio di errore?

Quando il debug è attivo, può comparire un errore PHP. Il primo messaggio utile contiene spesso file, riga, classe, modulo o tipo di errore.

Perché ti dico questo? Perché molti leggono “Fatal error” e vanno nel panico. In realtà quella riga è una mappa.

Fatal error: Uncaught Error: Class 'Product' not found

Significato probabile: problema di autoload, override, cache o file mancanti.

Allowed memory size of 134217728 bytes exhausted

Significato probabile: memoria PHP esaurita. Qui il sospetto va sul memory limit PrestaShop o su un processo troppo pesante.

Call to undefined method Tools::...

Significato probabile: codice non compatibile con la versione PrestaShop o override vecchio.

Cannot redeclare class...

Significato probabile: classe dichiarata due volte. Controlli override duplicati o moduli che caricano lo stesso file.

Warning: require_once(...): failed to open stream

Significato probabile: file mancante, permessi errati o deploy incompleto.

Minuto 12-15: come identificare il colpevole probabile?

Il percorso dell’errore spesso dice già dove guardare. Se compare /modules/nome_modulo/, il primo sospetto è quel modulo.

Se compare /themes/nome_tema/, guardi tema o template. Se compare /override/, controlli gli override. Se compare var/cache, può essere cache corrotta.

Quando vede classes, controllers o Adapter, non salti subito alla conclusione che il core sia rotto. Potrebbe essere un override, una compatibilità PHP o un modulo che interferisce.

Come si attiva _PS_MODE_DEV_ su PrestaShop?

Si attiva modificando il file defines.inc.php e impostando _PS_MODE_DEV_ su true. Serve per mostrare l’errore nascosto dietro la schermata bianca PrestaShop.

È una diagnosi, non una cura. Il debug mostra il problema. Dopo deve decidere l’intervento corretto.

Dove si trova defines.inc.php?

Il percorso standard è:

/config/defines.inc.php

Può accedere via FTP, SFTP, file manager dell’hosting o SSH. Cerchi questa riga:

define('_PS_MODE_DEV_', false);

E la trasformi in:

define('_PS_MODE_DEV_', true);

Se dopo il salvataggio la schermata bianca PrestaShop mostra un errore, ha già fatto il passo più importante: ha smesso di lavorare al buio.

Quando va disattivato il debug?

Il debug va disattivato appena ha recuperato il messaggio utile. Lasciarlo online può mostrare percorsi, file, classi e dettagli tecnici ai visitatori.

La sequenza corretta è: attiva, ricarica, copia errore, salva screenshot, disattiva. Se il problema nasce da update o compatibilità, approfondisca anche gli aggiornamenti PrestaShop.

Dove trovo i log quando PrestaShop resta bianco?

I log utili sono in tre punti: log PHP del server, cartella var/logs di PrestaShop e log dell’hosting. Se il debug non mostra nulla, quasi sempre il log PHP contiene l’indizio.

Il log è come il registro di cassa a fine giornata. Se il negozio si blocca alle 10:37, non controlli lo scontrino delle 8:15.

Come leggere l’error_log PHP?

Il PrestaShop error_log può trovarsi nella root del sito, nella cartella del dominio, in /logs o nel pannello hosting.

I nomi più comuni sono:

• error_log
• php_error.log
• error.log

Se usa SSH, può leggere le ultime righe così:

tail -n 100 error_log

Oppure seguire il log in tempo reale:

tail -f error_log

Il metodo è questo: apra la pagina bianca, ricarichi, poi guardi cosa viene scritto nel log nello stesso minuto. Non deve leggere tutto il passato del sito.

Che cosa cercare in var/logs?

Su PrestaShop 1.7, 8 e versioni recenti, i log applicativi si trovano spesso qui:

/var/logs/

I file tipici sono:

• prod.log, con errori in produzione;
• dev.log, più dettagliato quando il debug è attivo.

Può leggerli così:

tail -n 100 var/logs/prod.log

tail -n 100 var/logs/dev.log

PrestaShop var logs è uno dei punti più sottovalutati. Molti guardano solo la pagina bianca, quando l’informazione utile è già scritta lì.

Come capisco se il problema è il memory limit?

Il problema è probabilmente il memory limit PrestaShop quando nei log appare “Allowed memory size exhausted”. In quel caso PHP ha finito memoria prima di completare l’operazione.

Non ti dico che basta alzare un numero. Ti dico che quel numero ti dice dove guardare.

Quale messaggio indica memoria insufficiente?

Il messaggio tipico è questo:

Fatal error: Allowed memory size of 134217728 bytes exhausted

Dato citabile 2026: il valore 134217728 bytes corrisponde a 128 MB, perché 128 × 1024 × 1024 = 134.217.728 byte. La fonte è la conversione binaria standard usata da PHP nei messaggi di memoria.

Questo errore può comparire durante import catalogo, rigenerazione immagini, back office lento, moduli statistiche, feed prodotto o checkout con molte regole carrello.

Dove si aumenta il memory_limit?

Dipende dall’hosting. Può essere nel pannello hosting, in php.ini, in .user.ini, in .htaccess se supportato, oppure nella configurazione PHP-FPM.

Esempi:

memory_limit = 256M

memory_limit = 512M

Aumentare il memory limit PrestaShop può sbloccare l’operazione, ma non sempre risolve la causa. Se un modulo consuma troppo, la schermata bianca PrestaShop può tornare.

Come capisco se dipende da un modulo incompatibile?

Se l’errore cita una cartella dentro /modules/, il problema può dipendere da quel modulo. La verifica corretta è disattivarlo in sicurezza e controllare se il sito torna visibile.

Non deve cancellare il modulo. Deve isolarlo, documentare la modifica e poter tornare indietro.

Quali indizi indicano un modulo rotto?

L’indizio più chiaro è un percorso come questo:

/modules/nome_modulo/

Gli errori tipici sono metodo inesistente, classe non trovata, incompatibilità con PHP 8, template Smarty rotto, hook non compatibile o override installato dal modulo.

Fatal error: Uncaught Error: Call to undefined method NomeModulo::...

Se la PrestaShop schermata bianca dopo aggiornamento modulo compare subito dopo un update, il sospetto è ancora più forte. Ma anche qui: prima log, poi intervento.

Come disattivare un modulo se il back office è bianco?

Se il back office non si apre, può rinominare temporaneamente la cartella del modulo via FTP o SFTP. Non la cancelli.

Da:

/modules/nome_modulo

A:

/modules/nome_modulo_OFF

Poi ricarichi la pagina colpita e controlli se il sito torna visibile. Segni sempre cosa ha modificato e a che ora.

Gli interventi via database esistono, ma non vanno improvvisati. Una query sbagliata in emergenza può costare più tempo del problema iniziale.

Cosa fare se la schermata bianca compare dopo un aggiornamento?

Se la schermata bianca PrestaShop compare dopo un aggiornamento, il primo sospetto è una incompatibilità tra modulo, tema, versione PrestaShop o versione PHP. Il log dice quale pezzo si è rotto.

Quali sono questi aspetti? Ultimo file modificato, modulo aggiornato, versione PHP richiesta e punto preciso dove il sito si ferma.

Aggiornamento modulo: cosa controllare subito?

Controlli l’ultimo modulo aggiornato, la compatibilità dichiarata dal produttore e la versione PHP richiesta. Guardi anche se il modulo ha generato override.

Esempio operativo: aggiorna un modulo pagamento, poi il checkout diventa bianco. Se il log cita /modules/nomepagamento/, non ha senso toccare menu, categorie o tema.

Aggiornamento PHP: perché può rompere PrestaShop?

Alcuni moduli vecchi non sono compatibili con versioni PHP più recenti. Possono usare funzioni deprecate, firme di metodo incompatibili o librerie non aggiornate.

Senza offesa: cambiare PHP tre volte per tentativi non è manutenzione. È panico tecnico con un costo in ore.

Quali errori reali posso trovare nei log?

Gli errori più utili sono “Fatal error”, “Uncaught Error”, “Allowed memory size exhausted” e “Class not found”. Sono loro che indicano il punto tecnico da cui partire.

Usi questa tabella come primo filtro, non come diagnosi definitiva.

Quando conviene risolvere da soli e quando chiamare un tecnico?

Può provare da solo se l’errore indica chiaramente un modulo e ha un backup recente. Serve un tecnico quando l’errore tocca core, database, override, checkout, pagamenti o back office irraggiungibile.

Non è un’offesa. È una valutazione imprenditoriale: quanto costa continuare a tentativi?

Quando può intervenire internamente?

Può intervenire internamente se ha accesso FTP o SFTP, backup recente e un log chiaro. Per esempio, il log cita un singolo modulo e lei può rinominarlo senza perdere dati.

• Ha accesso FTP/SFTP.
• Ha un backup recente e verificato.
• Il log indica chiaramente un modulo.
• Può mettere il sito in manutenzione.
• Sa tornare indietro.
• Documenta ogni modifica.

Se il tema è la stabilità generale del negozio, lavori anche sulla manutenzione PrestaShop. Le emergenze non si eliminano tutte, ma si riducono.

Quando non conviene improvvisare?

Non conviene improvvisare se il checkout è bianco, il back office è irraggiungibile o i pagamenti non funzionano. Qui ogni tentativo può peggiorare il danno.

Si fermi anche davanti a errori database, file core modificati, aggiornamenti multipli o assenza di backup verificato. Meglio perdere 10 minuti a decidere bene che 5 ore a rompere altro.

Il pivot è mentale. Un e-commerce non si gestisce inseguendo emergenze. Si gestisce sapendo quando intervenire, quando fermarsi e quando delegare.

Qual è la checklist rapida per trovare l’errore vero?

La checklist è: segnare l’orario, attivare debug, leggere error_log PHP, controllare var/logs, identificare file e modulo citati, poi intervenire solo sul punto indicato dal log.

Questa è la differenza tra diagnosi e tentativo. La diagnosi restringe il campo, il tentativo lo allarga.

Checklist operativa in 10 punti

1. Segni l’ora esatta del problema.
2. Annoti l’ultima modifica fatta.
3. Verifichi se il problema è front office, back office o pagina specifica.
4. Attivi _PS_MODE_DEV_.
5. Ricarichi la pagina bianca.
6. Copi l’errore mostrato.
7. Legga il error_log PHP.
8. Legga var/logs/prod.log e var/logs/dev.log.
9. Cerchi modulo, tema, override o memory limit PrestaShop.
10. Disattivi debug e decida l’intervento.

Cosa non fare durante l’emergenza?

Non aggiorni altri moduli, non cancelli file core e non disattivi moduli a raffica. Non cambi PHP tre volte e non ripristini backup vecchi senza sapere cosa perde.

Non lasci nemmeno il debug attivo. È utile per la diagnosi, ma non deve restare esposto online.

Cosa fare se dopo 15 minuti non ho trovato la causa?

Se dopo 15 minuti non ha una causa chiara, si fermi. Continuare a tentativi può peggiorare il danno e rendere più lungo anche l’intervento tecnico successivo.

Il titolare non deve diventare sistemista durante un’emergenza. Deve capire abbastanza per decidere bene.

Perché fermarsi è una scelta imprenditoriale?

Se in negozio salta il quadro elettrico, non smonta tutto l’impianto. Isola il problema, evita danni e chiama chi lo risolve.

Con PrestaShop vale la stessa logica. La schermata bianca PrestaShop è un sintomo, non una diagnosi.

Non ti dico di chiamare sempre un tecnico. Ti dico di non pagare 6 ore di panico per risparmiare un intervento strutturato.

Vuole andare sul sicuro con la schermata bianca PrestaShop?

Se il sito è bianco, gli ordini sono fermi e i log non sono chiari, serve una diagnosi tecnica. Prima si trova l’errore vero, poi si decide l’intervento corretto.

Può richiedere un Audit Tecnico Approfondito PrestaShop: costa 497 EUR e l’obiettivo è trovare la causa reale del problema in 24-48h. Non promette magia. Promette diagnosi seria su debug, log, moduli, tema, override, server e compatibilità.

Se vuole evitare tentativi a caso sulla sua schermata bianca PrestaShop, può partire da qui: francescoingrosso.com

Domande frequenti

La schermata bianca PrestaShop è sempre un errore 500?

Non sempre viene mostrato come errore 500, ma spesso la causa tecnica è simile. Un errore PHP o server blocca la risposta e PrestaShop, in produzione, può nascondere il messaggio mostrando solo una pagina bianca.

Posso lasciare _PS_MODE_DEV_ attivo finché risolvo?

No. Va lasciato attivo solo il tempo necessario per leggere l’errore. Può esporre percorsi, file e dettagli tecnici del sito. Attivi, copi l’errore, faccia screenshot e poi lo disattivi.

Se il log cita un modulo, posso cancellarlo?

No, non lo cancelli durante l’emergenza. Può rinominare temporaneamente la cartella del modulo per isolarlo, segnando la modifica. Cancellare file senza backup può rendere più difficile il ripristino.

Aumentare il memory_limit risolve la pagina bianca?

Solo se la causa è davvero memoria insufficiente. Se il log mostra “Allowed memory size exhausted”, aumentare il limite può aiutare, ma bisogna capire quale processo consuma troppo. Altrimenti il problema può tornare.

Quando devo chiamare un tecnico PrestaShop?

Chiami un tecnico se l’errore riguarda checkout, pagamenti, database, core, override o back office irraggiungibile. Lo stesso vale se non ha backup verificato o se dopo 15 minuti non ha una causa chiara.