PrestaShop non funziona dopo un aggiornamento: guida al ripristino senza panico

Guida al ripristino di PrestaShop dopo un aggiornamento andato storto

Il tuo PrestaShop non funziona dopo un aggiornamento? Le cause più comuni sono quattro: modulo incompatibile con il nuovo core, versione PHP sbagliata sul server, override del tema corrotti, cache non svuotata. La soluzione parte sempre dalla lettura dei log — non dal browser — e richiede interventi chirurgici, non tentativi alla cieca.

Il sito è giù. Pagina bianca, errore 500, schermata nera. Hai aggiornato PrestaShop — o un modulo, o il PHP del server — e adesso il negozio non risponde più. Ogni minuto che passa è un ordine che non arriva.

Fermati. Non cliccare su nulla ancora.

Intervenire senza una diagnosi precisa è come smontare pezzi a caso su un'auto in panne sul ciglio dell'autostrada: rischi di trasformare un problema risolvibile in un disastro completo. Questa guida ti porta dalla diagnosi alla soluzione, passo per passo, con percorsi reali e comandi copiabili.

Perché PrestaShop si rompe dopo un aggiornamento (le cause reali)

Un aggiornamento non rompe mai un sito "a caso". C'è sempre una causa identificabile. Il problema è che la pagina bianca o l'errore 500 che vedi nel browser ti nasconde questa causa: mostra solo la conseguenza.

Le macro-cause sono quattro. Conoscerle ti permette di leggere i log in modo intelligente, invece di procedere per tentativi.

Incompatibilità di moduli PrestaShop

Hai aggiornato il core da 1.7.x a 8.x, o anche solo da una minor release all'altra. Uno o più moduli installati usano metodi che nella nuova versione non esistono più, o hanno cambiato nome. PHP lancia un errore fatale e il sito si blocca prima di caricarsi.

È esattamente come cambiare la serratura di un negozio fisico senza ridistribuire le chiavi al personale: la porta non si apre più, anche se tutti erano autorizzati fino al giorno prima. Il problema non è la chiave — è che la serratura nuova non la riconosce.

Cambio di versione PHP sul server

L'hosting ha aggiornato PHP dalla 7.4 alla 8.1 o 8.2, spesso senza un avviso esplicito. PrestaShop 1.7 non è compatibile con PHP 8.x: alcune funzioni deprecate in 7.x sono state rimosse definitivamente. Il sito crasha prima ancora di mostrare la homepage.

Se la combinazione non corrisponde, il sito non parte.

Override del tema o del core corrotti

PrestaShop permette di sovrascrivere classi e controller del core tramite la cartella /override/. È uno strumento potente, ma fragile: dopo un aggiornamento, quegli override possono richiamare classi o metodi che nella nuova versione non esistono più.

Sono come istruzioni operative scritte per il vecchio gestionale, applicate al nuovo: il sistema non le riconosce e va in crash.

Cache e file compilati non svuotati

PrestaShop compila i template Smarty e mantiene una cache aggressiva. Dopo un aggiornamento, i file compilati vecchi possono collidere con il nuovo codice. Da sola, la cache è raramente la causa principale — ma amplifica qualsiasi altro problema e impedisce di verificare se il tuo intervento ha funzionato. Sempre svuotarla, dopo ogni modifica.

Prima di toccare qualsiasi cosa: il backup

Se hai eseguito un backup prima dell'aggiornamento, sei in una posizione molto migliore. Se non lo hai fatto, fallo adesso — anche dello stato rotto — prima di qualsiasi intervento.

Fotografa la scena del sinistro prima di spostare le auto. Un backup dello stato attuale sembra inutile, ma se nei prossimi passi peggiori qualcosa, avrai uno snapshot da cui tornare.

Backup del database via riga di comando:

mysqldump -u UTENTE -p NOME_DATABASE > backup_emergenza_$(date +%Y%m%d).sql

Backup dei file del sito:

tar -czf backup_files_$(date +%Y%m%d).tar.gz /var/www/html/tuonegozio/

Se non hai accesso SSH, usa phpMyAdmin per il database e il file manager del tuo hosting per i file. Poi, e solo poi, procedi.

Come leggere l'errore reale: il log è la diagnosi, il browser mente

La pagina bianca è un sintomo. L'errore 500 è un sintomo. Il log è la diagnosi. Devi andare a leggerlo lì, non nel browser.

Attiva la modalità debug di PrestaShop

Se riesci ancora ad accedere al back-office, vai su Parametri Avanzati → Performance e attiva la modalità debug.

Se il back-office non risponde, puoi forzare il debug direttamente via FTP. Modifica il file:

/config/defines.inc.php

Cerca questa riga:

define('_PS_MODE_DEV_', false);

Cambiala in:

define('_PS_MODE_DEV_', true);

Salva, ricarica il sito. Invece della pagina bianca, vedrai l'errore completo con lo stack trace nel browser. Copialo integralmente: è il punto di partenza della diagnosi.

Leggi i log di PrestaShop

PrestaShop scrive i log in:

/var/logs/YYYY-MM-DD.log

Apri il file della data di oggi e filtra per le righe che contengono CRITICAL, ERROR o Fatal error. Un esempio reale di log con modulo incompatibile:

[2024-11-14 09:42:11] request.CRITICAL: Uncaught PHP Exception
Symfony\Component\Debug\Exception\FatalErrorException:
"Call to undefined method Module::getInstanceByName()"
in /modules/nome_modulo/nome_modulo.php line 247

Questa riga ti dice esattamente cosa è successo e dove. Non devi indovinare nulla.

Leggi l'error_log del server

Se il log di PrestaShop è vuoto o irraggiungibile, controlla il log di PHP/Apache/Nginx del server:

/var/log/apache2/error.log
/var/log/nginx/error.log

Su hosting condivisi con cPanel: sezione Log → Error Log. Cerca righe con PHP Fatal error o PHP Parse error: ti indicano il file esatto e il numero di riga dove PHP si è fermato.

Nei negozi che seguo, la maggior parte degli interventi post-aggiornamento si risolve in meno di un'ora proprio perché si parte dai log — e non da tentativi alla cieca sul back-office.

Diagnosi rapida: in quale scenario sei?

Dopo aver letto i log, puoi identificare il tuo scenario. Eccoli con le azioni corrispondenti.

Scenario A — Errore su un modulo specifico

Il log punta a un file dentro /modules/nome_modulo/. Azione:

1. Accedi al server via FTP/SFTP o file manager dell'hosting.
2. Rinomina la cartella del modulo: da /modules/nome_modulo/ a /modules/nome_modulo_DISABLED/. PrestaShop non la trova più e non tenta di caricarla.
3. Svuota la cache (vedi sezione successiva).
4. Ricarica il sito.

Se torna su, hai trovato il colpevole. Aggiorna o disinstalla quel modulo dall'area modulistica del back-office.

Per approfondire come gestire i moduli in modo sicuro prima degli aggiornamenti, leggi come aggiornare i moduli PrestaShop senza rischi.

Scenario B — Incompatibilità con la versione PHP

Il log mostra errori come Deprecated: Function xxx is deprecated o Fatal error: Call to undefined function xxx su file del core. Azione:

1. Controlla la versione PHP attiva sul tuo hosting (di solito da cPanel o Plesk, sezione PHP Version).
2. Confronta con la tabella di compatibilità sopra.
3. Torna alla versione PHP compatibile con la tua versione di PrestaShop.
4. Svuota la cache e verifica.

Scenario C — Override corrotti

Il log punta a file dentro /override/classes/ o /override/controllers/. Azione:

# Rinomina l'intera cartella override
mv /var/www/html/tuonegozio/override/ /var/www/html/tuonegozio/override_BACKUP/

# Crea una cartella override vuota
mkdir /var/www/html/tuonegozio/override/

Svuota la cache. Se il sito torna su, gli override erano il problema: dovranno essere riscritti o aggiornati per la nuova versione del core.

Svuotare la cache: il passo che non si salta mai

Dopo ogni intervento, sempre svuotare la cache prima di dichiarare risolto o peggiorato. Senza questo passaggio, stai valutando lo stato precedente — non il risultato del tuo intervento.

Metodo 1 — Da back-office (se disponibile):
Parametri Avanzati → Performance → Svuota la cache.

Metodo 2 — Via SSH (se il back-office non risponde):

# Cache PrestaShop 8.x
rm -rf /var/www/html/tuonegozio/var/cache/*

# Cache PrestaShop 1.7.x (Smarty)
rm -rf /var/www/html/tuonegozio/cache/smarty/compile/*
rm -rf /var/www/html/tuonegozio/cache/smarty/cache/*

Non appena il sito torna operativo, ricordati di disattivare il debug mode: riporta _PS_MODE_DEV_ a false nel file defines.inc.php.

Il rollback: quando ha senso e quando no

Il rollback cieco è l'errore più comune in questa situazione. Ripristini il backup, il sito torna su — e cinque giorni dopo crasha di nuovo, identico, perché la causa vera non è mai stata affrontata.

Mi capita spesso di vedere store dove il rollback è stato eseguito correttamente, ma il problema si è ripresentato perché l'hosting aveva aggiornato PHP silenziosamente: il backup del sito non ha cambiato la versione PHP sul server, e il modulo incompatibile era ancora lì, pronto a bloccare tutto alla prima richiesta.

Il rollback ha senso quando:

• Hai identificato la causa e, dopo il ripristino, la risolvi prima di riaggiornare.
• L'urgenza è assoluta (sito live con ordini in corso) e puoi gestire la causa in un secondo momento.
• Il backup è recente — massimo 24-48 ore — e non perdi ordini o dati rilevanti.

Il rollback non basta quando:

• Il backup è datato: perdi ordini, clienti registrati, movimentazioni di magazzino.
• La causa è sul server (versione PHP, configurazione hosting): il backup ripristinato subirà lo stesso problema.
• I log mostrano errori multipli sovrapposti: c'è qualcosa di più profondo che un rollback non risolve.

Per capire come strutturare backup regolari che ti proteggano davvero, vai a leggere come configurare il backup automatico di PrestaShop.

Checklist di emergenza: cosa fare nei primi 30 minuti

Tienila aperta mentre lavori. Ordinata, metodica — l'opposto del panico da click compulsivo.

1. ✅ Non toccare nulla finché non hai letto i log.
2. ✅ Backup dello stato attuale (anche se rotto) prima di ogni intervento.
3. ✅ Attiva il debug mode — via back-office o via file defines.inc.php.
4. ✅ Leggi i log PrestaShop in /var/logs/ e filtra per CRITICAL / ERROR.
5. ✅ Leggi l'error_log del server se il log PS è vuoto.
6. ✅ Identifica file/modulo incriminato dal traceback dell'errore.
7. ✅ Intervieni chirurgicamente (rinomina modulo, correggi PHP, disabilita override).
8. ✅ Svuota la cache prima di ogni verifica.
9. ✅ Disattiva il debug mode non appena il sito torna operativo.

Quando serve un esperto (e perché aspettare costa di più)

Ci sono situazioni in cui il fai-da-te rischia concretamente di peggiorare il problema:

• I log mostrano errori multipli sovrapposti e non riesci a isolare la causa principale.
• Hai già disabilitato moduli e svuotato la cache, ma il sito è ancora giù.
• Il database mostra errori o tabelle corrotte dopo un aggiornamento interrotto a metà.
• Non hai accesso SSH e puoi operare solo dal pannello dell'hosting.
• Il sito è live con ordini in corso e ogni ora di downtime ha un costo misurabile.

In questi casi, procedere per tentativi senza una diagnosi precisa è come cambiare parti a caso su un'auto senza sapere dov'è il guasto: spendi tempo, spendi soldi, e il problema è ancora lì — spesso aggravato.

Se vuoi la certezza di individuare la causa esatta senza rischiare di perdere dati o prolungare il downtime, l'Audit Tecnico Approfondito PrestaShop (€497) è l'opzione strutturata: in 24-48 ore vengono analizzati log, versioni, moduli, database e configurazione server, e ricevi un report con la causa esatta e le azioni correttive da eseguire. Diagnosi completa, nessun tentativo alla cieca.

Puoi richiedere l'audit direttamente su francescoingrosso.com.

Conclusione: la diagnosi prima di tutto

PrestaShop che non funziona dopo un aggiornamento fa paura, soprattutto quando il negozio è fermo e gli ordini non arrivano. Ma nella quasi totalità dei casi la causa è tecnica, identificabile e risolvibile — a patto di leggerla nei posti giusti e intervenire con metodo invece che per tentativi.

Il log non mente mai. Il browser, sì.

Segui la sequenza: leggi l'errore reale, isola il componente responsabile, intervieni in modo chirurgico, svuota la cache, verifica. Se dopo questi passi il sito è ancora giù — o se la situazione è più complessa di quanto sembri — non aspettare altri giorni. Ogni ora di downtime ha un costo reale. La diagnosi professionale ne ha uno che, quasi sempre, è inferiore.

Hai bisogno di sapere con certezza cosa ha rotto il tuo PrestaShop? Visita francescoingrosso.com e richiedi l'Audit Tecnico Approfondito PrestaShop: causa trovata in 24-48 ore, €497, zero tentativi alla cieca.

Domande frequenti

PrestaShop mostra pagina bianca dopo l'aggiornamento: da dove parto?

Attiva il debug mode modificando il file /config/defines.inc.php e imposta _PS_MODE_DEV_ su true. Ricarica il sito: al posto della pagina bianca vedrai l'errore completo. Poi leggi i log in /var/logs/ per identificare il file o il modulo che causa il crash.

Posso fare il rollback del backup senza capire la causa?

Puoi farlo per ripristinare il sito in emergenza, ma il problema si ripresenterà. Se la causa è la versione PHP sul server o un modulo incompatibile, il backup ripristinato subirà lo stesso crash alla prossima occasione. Il rollback ha senso solo se poi risolvi la causa reale.

Come capisco quale versione PHP è compatibile con la mia versione di PrestaShop?

PrestaShop 1.7.6–1.7.8 richiede PHP 7.4; PrestaShop 8.0 richiede PHP 8.1; PrestaShop 8.1 e 8.2 girano su PHP 8.1 o 8.2. Puoi verificare la versione PHP attiva dal pannello del tuo hosting (cPanel, Plesk o simili) nella sezione dedicata alla configurazione PHP.

Ho disabilitato tutti i moduli ma il sito è ancora giù: cosa faccio?

Se la disabilitazione dei moduli non risolve, il problema potrebbe essere negli override (cartella /override/), nella versione PHP del server, o in un errore avvenuto durante l'aggiornamento che ha corrotto file del database o del core. In questo scenario la diagnosi fai-da-te diventa rischiosa: è il momento di chiamare un tecnico specializzato.

Quanto tempo ci vuole per risolvere un PrestaShop giù dopo un aggiornamento?

Dipende dalla causa. Se leggi i log e il problema è un singolo modulo incompatibile, si risolve in 30-60 minuti. Se ci sono errori multipli sovrapposti o il database è coinvolto, i tempi si allungano. Con l'Audit Tecnico Approfondito PrestaShop (€497) la diagnosi completa arriva in 24-48 ore, con il report delle azioni correttive incluso.