ps_checkout sparisce dal checkout: colpa di LiteSpeed Cache

Era un mercoledì mattina quando è arrivato il messaggio: “il checkout non mostra più i metodi di pagamento”. Lo shop attivo, gli ordini fermi, il cliente nel panico. Apro il backoffice: ps_checkout risulta installato, attivo, configurato a dovere. Eppure nel frontend, niente. E ps_checkout non è un modulo qualsiasi: è uno dei più importanti per chi vende online con PrestaShop. Se sparisce lui, sparisce il modo di pagare - e con lui il fatturato.

Ambiente del caso: PrestaShop 8, modulo ps_checkout 8.5, LiteSpeed Cache 1.4.

⚠️ Il sintomo: checkout PrestaShop senza metodi di pagamento

Il cliente non riusciva a concludere l’ordine: la sezione dei pagamenti era semplicemente vuota. Nessuna schermata di errore, log puliti a un primo sguardo, modulo installato e attivo.

E qui sta la parte peggiore. Un metodo di pagamento che non si vede è un danno gravissimo perché è silenzioso: non genera un alert, non rompe niente di evidente. Ma chi compra online è diffidente per natura: appena vede un errore, o qualcosa di diverso da quello che si aspetta, scappa via in un attimo. Non ti scrive per segnalare il problema, chiude la scheda e va altrove. Te ne accorgi dagli ordini che non arrivano, non da un messaggio di sistema.

🛠️ Perché LiteSpeed Cache lo rompe

LiteSpeed Cache sostituisce (override) la classe classes/Hook.php di PrestaShop. Nel suo override concatena il marcatore con l’output dell’hook senza verificare che quell’output sia davvero una stringa:

// override LiteSpeed (semplificato)
$html = Hook::exec($hookName, $params);
$output = $marker . $html; // se $html è un array, qui esplode

Il punto è che alcuni hook non restituiscono HTML: paymentOptions restituisce un array di oggetti PaymentOption[]. La concatenazione lo forza a stringa, scatta un Array to string conversion e il metodo di pagamento svanisce dal checkout.

🛠️ La diagnosi senza accessi SSH

Il cliente aveva solo l’FTP, niente accessi al server. Ho usato una tecnica che applico spesso: uno script PHP read-only, protetto da un token nell’URL, caricato in una cartella di servizio. Mi permette di eseguire l’hook in due modi e capire dove si rompe, senza chiedere credenziali sensibili:

[ok]   $module->hookPaymentOptions()  =>  array(1) { [0] => PaymentOption }
[FAIL] Hook::exec('paymentOptions')   =>  "Array to string conversion" (Hook.php override LiteSpeed)

Chiamato direttamente, il modulo funziona e restituisce l’array corretto. Passando dal dispatcher sovrascritto da LiteSpeed, salta tutto. Da lì la certezza: il problema non è nel modulo, è nell’override. L’ordine con cui leggo uno shop quando ho solo l’FTP, dagli header ai log del pannello, l’ho messo in fila nella guida alla diagnosi di PrestaShop senza SSH.

Chiamato direttamente il modulo funziona.
È il dispatcher sovrascritto da LiteSpeed a rompere tutto.

✅ La soluzione sostenibile: escludere il modulo

Per la maggior parte dei siti non serve toccare il codice. Dal pannello di LiteSpeed Cache si esclude ps_checkout dall’ottimizzazione: è la strada più semplice, reversibile e alla portata anche di chi non sviluppa.

Il pannello di LiteSpeed Cache in cui si toglie ps_checkout dalla cache condivisa della pagina: nello screenshot il modulo è gestito a parte, come blocco privato calcolato per ogni utente.

🛠️ Il fix definitivo: la guardia di tipo

Chi mette le mani nel codice può chiudere il problema alla radice, con una guardia sul tipo prima di concatenare:

$output = $marker . (is_string($html) ? $html : ''); // guardia sul tipo

Una riga, e il metodo di pagamento torna in checkout.

✅ Come prevenirlo (e perché non è un controllo una tantum)

Ogni override della classe Hook deve distinguere il tipo del valore restituito: gli hook non sono solo HTML.

Ma c’è un punto più importante. Questo non è un problema da sistemare una volta e dimenticare. I moduli cambiano anche senza che te ne accorga: un aggiornamento di LiteSpeed, una nuova versione di ps_checkout, un modulo terzo che entra in conflitto. È un effetto butterfly: basta un update apparentemente innocuo, da un’altra parte, e il checkout torna a perdere un pezzo. Dopo ogni aggiornamento varrebbe la pena ricontrollare che tutti i metodi di pagamento siano ancora al loro posto - cosa che, realisticamente, nessuno fa a mano.

✅ Hai lo stesso problema?

Se sul tuo PrestaShop il checkout perde un metodo di pagamento, o un modulo sparisce dopo un aggiornamento, te lo diagnostico e risolvo - anche senza accessi SSH.
Fa parte del mio servizio di assistenza PrestaShop professionale.

E se vuoi smettere di preoccupartene: posso metterti in piedi un monitoraggio automatizzato che verifica di continuo che metodi di pagamento e moduli critici siano sempre attivi, e ti avvisa prima che sia un cliente ad accorgersene.

Hai un caso simile? Scrivimi da uno dei canali qui sotto: ti rispondo entro 24 ore.