PrestaShop bloccato in manutenzione: come uscirne senza perdere ordini

PrestaShop bloccato in manutenzione: come uscirne senza perdere ordini

Se PrestaShop è bloccato in manutenzione dopo un upgrade fallito, la causa è quasi sempre una tra queste quattro: aggiornamento interrotto a metà, file .htaccess corrotto, cache Smarty non ripulita o flag PS_SHOP_ENABLE a 0 nel database. Nella maggior parte dei casi si risolve in poche ore, senza toccare gli ordini già registrati.

Hai lanciato l'aggiornamento e ora il negozio mostra solo la pagina "Sito in manutenzione". I clienti non entrano, le vendite si fermano, e ogni minuto che passa è fatturato che se ne va altrove. Prima di farti prendere dal panico: i tuoi ordini pregressi sono al sicuro nel database, e nella stragrande maggioranza dei casi il problema si risolve senza dover ripristinare tutto da un backup vecchio. Ma serve procedere con metodo, non a tentativi.

Pensa a un negozio fisico che deve riaprire dopo aver spostato gli scaffali durante la notte: se lasci la saracinesca abbassata "per sicurezza" mentre finisci di sistemare la merce, perdi i clienti che passano davanti alla vetrina in quel momento. Non tornano più tardi: entrano dal concorrente a fianco. Un e-commerce in manutenzione funziona esattamente così — ogni ora bloccata è traffico che si disperde e non recuperi cliccando "riprova".

Il sintomo: cosa succede davvero quando PrestaShop va in manutenzione dopo un upgrade fallito

Il pattern è quasi sempre identico, negozio dopo negozio. Lanci l'aggiornamento — dal modulo Autoupgrade o manualmente via FTP — e qualcosa si interrompe: timeout del server, memoria PHP insufficiente, connessione FTP caduta, permessi sbagliati su una cartella. Il sito resta a metà strada, né sulla versione vecchia né su quella nuova, e PrestaShop attiva automaticamente la modalità manutenzione per proteggerti da un frontend rotto davanti ai clienti.

Il problema reale non è tanto l'interruzione in sé, quanto il fatto che questa protezione — pensata per essere temporanea — spesso resta attiva anche quando la causa che l'ha generata è già risolvibile o addirittura già risolta. Il negozio resta chiuso non perché sia irrimediabilmente rotto, ma perché nessuno ha ancora spento l'interruttore giusto. Nei progetti che seguo, questo è quasi sempre l'errore di fondo: si interviene su tutto tranne che sulla causa reale del blocco.

La diagnosi seria: le quattro cause reali (non le supposizioni da forum)

Prima di toccare qualsiasi file, guarda nei posti giusti, nell'ordine di frequenza reale che emerge negli interventi d'emergenza su PrestaShop. Sono quattro cause, quasi sempre una di queste — a volte una combinazione di due.

1. Upgrade interrotto a metà (il caso più comune)

Il modulo Autoupgrade copia i nuovi file core, aggiorna le tabelle del database ed esegue gli script di migrazione. Se il processo si ferma prima della fine — timeout, connessione caduta, memoria PHP esaurita — ti ritrovi con una struttura ibrida: parte dei file già alla versione nuova, il database ancora vecchio (o viceversa). PrestaShop, non riconoscendo uno stato coerente, blocca l'accesso.

Il segnale distintivo lo trovi nella cartella admin/autoupgrade/: backup parziali, log di aggiornamento, file di stato che indicano l'ultimo step eseguito prima dello stop. Non cancellare nulla lì dentro finché non hai capito esattamente a che punto si è fermato l'upgrade.

2. File .htaccess corrotto o sovrascritto male

Il file .htaccess nella root gestisce il routing degli URL: friendly URL, redirect, regole di riscrittura Apache. Durante un upgrade viene spesso rigenerato, e se la procedura si interrompe proprio in quel momento — o se il nuovo file contiene regole incompatibili con la configurazione del server — il risultato è un errore 500 mascherato dalla pagina di manutenzione, o un loop di redirect infinito.

Test pratico e a basso rischio: rinomina temporaneamente .htaccess in .htaccess.bak e ricarica il sito. Se il comportamento cambia (anche in peggio), hai isolato la causa.

3. Cache Smarty non ripulita dopo l'aggiornamento

PrestaShop compila i template Smarty in file PHP per velocizzare il rendering. Dopo un upgrade, i template compilati della versione vecchia restano nelle cartelle:

var/cache/prod/
var/cache/dev/

(su PrestaShop 1.7 e 1.8; su 1.6 i percorsi equivalenti sono cache/smarty/compile e cache/smarty/cache). Se questi file compilati fanno riferimento a template ora sostituiti, Smarty genera errori fatali PHP che il sistema interpreta come stato instabile, mantenendo la manutenzione attiva anche quando i file core sono già a posto.

La pulizia è a basso rischio e va sempre eseguita dopo qualsiasi intervento su un upgrade bloccato:

rm -rf var/cache/prod/*
rm -rf var/cache/dev/*

4. Il flag PS_SHOP_ENABLE nel database

È la causa che quasi nessuno controlla per prima, ed è invece la più diretta. PrestaShop decide se mostrare il sito o la pagina di manutenzione leggendo un valore preciso nella tabella ps_configuration (il prefisso ps_ può variare a seconda dell'installazione):

SELECT name, value FROM ps_configuration WHERE name = 'PS_SHOP_ENABLE';

Se il valore è 0, il negozio è forzatamente in manutenzione, indipendentemente da come stanno i file. Un upgrade interrotto può lasciare questo flag disattivato come misura di sicurezza automatica. Controlla anche PS_MAINTENANCE_IP, che contiene la lista di IP autorizzati a vedere il sito anche in manutenzione: se il tuo IP non è in lista, vedi la pagina di blocco anche tu, mentre il sito potrebbe già funzionare per altri.

Cosa fare subito: la sequenza corretta, senza toccare gli ordini

Segui questo ordine passo dopo passo, senza correggere due variabili insieme: se lo fai e il sito torna online, non saprai mai quale intervento ha risolto davvero, e la prossima volta ripartirai da zero.

1. Backup completo prima di toccare qualsiasi cosa. File e database. Anche se il sito sembra rotto, è nello stato in cui è ora la tua unica rete di sicurezza reale.
2. Leggi i log reali. Su PrestaShop 1.7/1.8:

   tail -n 100 var/logs/prod.log
   tail -n 100 var/logs/dev.log

   Su 1.6, con debug mode attivo (_PS_MODE_DEV_ a true in config/defines.inc.php), l'errore appare a video; altrimenti controlla l'error_log del server.
3. Verifica il flag PS_SHOP_ENABLE con la query indicata sopra. Se è a 0 e sei certo che nessun processo di aggiornamento sia ancora in corso, riattivalo:

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

   Attenzione: farlo mentre l'upgrade è realmente a metà può mostrare un frontend rotto ai clienti, peggio della pagina di manutenzione. Prima controlla il punto successivo.
4. Controlla lo stato dell'autoupgrade in admin/autoupgrade/. Se trovi tracce di un processo non concluso, scegli tra riprenderlo (se i backup sono integri) o eseguire un rollback controllato al backup pre-upgrade che il modulo genera automaticamente.
5. Pulisci la cache Smarty come indicato sopra, sempre, indipendentemente dagli altri step. È a basso rischio e risolve spesso errori "fantasma" legati a template compilati obsoleti.
6. Rigenera il file .htaccess. Rinomina quello esistente e lascia che PrestaShop lo ricrei al primo accesso all'admin, oppure ripristina quello del backup pre-upgrade.
7. Testa in navigazione anonima e da un IP diverso prima di dichiarare vittoria: la cache del browser e la lista PS_MAINTENANCE_IP possono darti falsi positivi o falsi negativi.

Un punto su cui puoi stare tranquillo: gli ordini già effettuati prima del blocco restano scritti nelle tabelle del database (ps_orders e collegate) e non vengono toccati da nessuna di queste operazioni, a patto di non eseguire un rollback del database a un punto precedente a quegli ordini. Per questo il backup al punto 1 non è una formalità burocratica: è la garanzia che, qualunque cosa tu faccia dopo, non perdi un solo ordine reale. Lo stesso principio vale se il problema nasce da carrelli abbandonati durante il blocco: i dati non spariscono, restano lì da recuperare una volta riaperto il negozio.

Quando la diagnosi fai-da-te non basta

Se dopo questi passaggi il sito resta bloccato, o ti trovi in uno di questi scenari, fermati prima di fare danni ulteriori.

• L'upgrade si è interrotto e non è chiaro quali tabelle del database siano state migrate e quali no: un rollback parziale mal eseguito crea incoerenze silenziose che emergono dopo, su ordini o scorte.
• Il log mostra errori PHP legati a moduli di terze parti non compatibili con la nuova versione core: capire quale disattivare senza spegnere funzionalità critiche richiede di leggere codice, non solo configurazione.
• Hai già provato a intervenire e ora il sito mostra un errore diverso da quello iniziale: segno che qualche modifica ha spostato il problema invece di risolverlo.
• Non hai un backup recente e affidabile, e ogni intervento comporta un rischio che non puoi permetterti di correre da solo.

Nei negozi che seguo, il momento più critico non è tecnico: è psicologico. Il proprietario continua a provare soluzioni trovate online mentre il tempo passa, e il vero costo non è la parcella di chi interviene — è ogni ora aggiuntiva di negozio chiuso mentre si procede per tentativi su un sistema che non si conosce a fondo. Capita spesso di vedere store che, dopo tre o quattro modifiche fatte "a intuito", si ritrovano con un problema più complesso di quello di partenza.

Vale anche la pena controllare, una volta riaperto il sito, che tutto il resto funzioni come prima: dalla gestione del checkout alle notifiche automatiche degli ordini, un upgrade interrotto può lasciare strascichi anche in aree apparentemente non collegate al blocco iniziale.

Se vuoi andare sul sicuro: l'Audit Tecnico Approfondito PrestaShop

Per chi non vuole giocarsi ore di fatturato su tentativi ed errori, propongo un Audit Tecnico Approfondito PrestaShop: analizzo i log reali, lo stato del database e la struttura dei file per individuare la causa esatta del blocco e le azioni correttive da eseguire, senza ipotesi generiche prese da un forum. Il costo è di 497 euro e la causa viene individuata in 24-48 ore, con un piano d'intervento chiaro da seguire — da soli o con il mio supporto — senza rischiare di peggiorare la situazione o perdere altri ordini nel frattempo.

Qualunque sia la situazione in cui ti trovi ora, il primo passo è smettere di procedere a tentativi e iniziare a leggere i dati reali del tuo sito. È l'unico modo per trasformare ore di panico in una diagnosi certa e in un negozio di nuovo aperto.

Domande frequenti

PrestaShop bloccato in manutenzione: perdo gli ordini già ricevuti?

No. Gli ordini restano scritti nel database, nella tabella ps_orders e collegate, e non vengono toccati dalle operazioni di ripristino descritte in questo articolo. L'unico rischio reale è un rollback del database a un punto precedente agli ordini stessi: per questo il backup prima di ogni intervento è fondamentale.

Quanto tempo serve per riaprire un negozio PrestaShop dopo un upgrade fallito?

Dipende dalla causa: se è solo cache Smarty o .htaccess, si risolve in poche ore. Se l'upgrade si è interrotto a metà con incoerenze tra file e database, servono più tempo e attenzione, perché ogni intervento va verificato prima di procedere al successivo.

Posso semplicemente disattivare la manutenzione dal flag PS_SHOP_ENABLE senza controllare altro?

Non è consigliato. Se l'upgrade è ancora a metà, riattivare il flag mostra ai clienti un frontend rotto, che è peggio della pagina di manutenzione. Prima verifica lo stato dell'autoupgrade e i log, poi intervieni sul flag.

Come capisco se il problema è .htaccess o cache Smarty?

Rinomina temporaneamente il file .htaccess in .htaccess.bak e ricarica il sito: se il comportamento cambia, hai isolato la causa. Se invece l'errore riguarda template o rendering delle pagine, pulisci prima la cache in var/cache/prod e var/cache/dev.

Quando conviene chiedere un intervento esterno invece di continuare da soli?

Quando il sito mostra un errore diverso da quello iniziale dopo i tuoi tentativi, quando non hai un backup recente affidabile, o quando l'upgrade ha lasciato incoerenze tra file e database che richiedono di leggere codice, non solo configurazione. In questi casi ogni ora persa costa più di un intervento mirato.