Restare su PrestaShop 1.6 o 1.7: quali rischi comporta e come valutarli

«Se funziona, non toccarlo» è un buon consiglio per quasi tutto, tranne che per il software esposto a Internet che incassa con carta. Un negozio su PrestaShop 1.6 o 1.7 può vendere ogni giorno senza un solo errore visibile e, allo stesso tempo, accumulare rischi che non si notano finché non esplodono.

Non si tratta di fare paura. Si tratta di capire che cosa significa essere fuori supporto, perché la decisione di restare o migrare sia tua e basata sui dati.

Cosa significa «senza supporto» in pratica

Il core non riceve più patch

Il ramo 1.6 si è chiuso con la 1.6.1.24 e il ramo 1.7 con la 1.7.8.11. Quando si scopre una nuova vulnerabilità nel core, la correzione viene pubblicata per i rami mantenuti. Per il tuo, nel migliore dei casi, qualcuno scrive una patch non ufficiale; nel peggiore, non c'è nulla.

E anche se sei sulla 1.7, su quale 1.7 sei? Molti negozi sono ancora su una 1.7.6 o una 1.7.7 senza le correzioni successive dello stesso ramo, che includevano fix di sicurezza.

I moduli restano indietro

Gli sviluppatori di moduli concentrano il lavoro sulle versioni attuali. Col tempo succede questo:

• Le nuove versioni dei moduli smettono di essere compatibili con il tuo negozio.
• Quando viene pubblicata una falla di sicurezza in un modulo, la versione corretta richiede un PrestaShop più recente.
• Alcuni autori abbandonano i loro moduli e nessuno li ricontrolla più.
• I gateway di pagamento cambiano le loro API e i loro requisiti, e i moduli vecchi smettono di funzionare o perdono funzioni.

Questo è, in pratica, il rischio più grande. Le campagne di massa contro PrestaShop sfruttano di solito vulnerabilità nei moduli, e un negozio che non può installare la versione corretta resta esposto a tempo indeterminato.

PHP senza supporto

PrestaShop 1.7.8 arriva al massimo a PHP 7.4, e le versioni precedenti anche meno. PHP 7.4 ha smesso di ricevere patch di sicurezza anni fa. Significa che il linguaggio stesso su cui gira il tuo negozio ha falle note che non verranno corrette.

Inoltre, gli hosting tolgono le vecchie versioni di PHP dai loro server. Arriva il giorno in cui il fornitore avvisa che alzerà la versione, o la alza direttamente, e il negozio smette di funzionare. Migrare di corsa per questo motivo è il modo peggiore di migrare.

Come valutare il tuo rischio

Non tutti i negozi vecchi hanno lo stesso rischio. Queste domande aiutano a capire dove sei:

Un negozio con molto fatturato, molti moduli di terze parti e senza sorveglianza è quello che ha più da perdere e quello con più probabilità di essere attaccato con successo.

Cosa si può fare nel frattempo

Se la migrazione non può essere immediata, ci sono misure che riducono il rischio:

• Passa all'ultima versione del tuo ramo: la 1.7.8.11 se sei sulla 1.7. È molto meno lavoro di una migrazione e chiude falle note.
• Alza PHP alla versione più alta supportata dal tuo PrestaShop, provando prima su una copia.
• Fai l'inventario dei moduli e rimuovi quelli che non usi, comprese le cartelle di quelli disinstallati.
• Aggiorna i moduli che hanno una versione compatibile, soprattutto quelli con controller pubblici.
• Blocca l'esecuzione diretta di PHP in modules/ e nelle cartelle di dati.
• Attiva la sorveglianza di file, dipendenti e configurazione dei pagamenti, per accorgerti presto se succede qualcosa.
• Backup giornalieri, fuori dal server e verificati.

Tutto questo fa guadagnare tempo. Non trasforma un negozio senza supporto in uno supportato. E più si rimanda, più l'uscita diventa costosa: ogni anno che passa aumenta la distanza tra la tua versione e quella attuale, i moduli senza un equivalente diretto e i dati da trasferire. Le migrazioni più semplici che facciamo sono quelle dei negozi che hanno fatto il salto quando potevano ancora scegliere il momento, non di quelli che hanno aspettato che qualcosa smettesse di funzionare.

Come pianificare l'uscita

1. Decidi la destinazione. Oggi la scelta ragionevole è passare direttamente a PrestaShop 9, senza tappa intermedia sulla 8, a meno che un modulo indispensabile non esista ancora per la 9.
2. Fai l'inventario delle funzioni, non dei moduli. Elenca ciò che fa il negozio (fatturazione, spedizioni, ERP, pagamenti, SEO) e, per ogni cosa, quale modulo la risolve oggi e quale lo farà nella 9. Spesso una buona parte è di troppo.
3. Calcola il lavoro sul tema. Un tema della 1.6 non funziona nella 9, e uno della 1.7 raramente va bene così com'è. È la voce più grande di molte migrazioni.
4. Scegli il momento. Evita le campagne forti del tuo settore. Una migrazione ben pianificata richiede settimane di test, non giorni.
5. Fai una prova completa su una copia prima del giorno del passaggio.

Il vantaggio di pianificare per tempo è che il calendario lo scegli tu. Se aspetti che l'hosting tolga PHP 7.4 o che arrivi un incidente, lo sceglierà qualcun altro.

Come risolverlo in PrestaShop

In Rekire lavoriamo ogni giorno con negozi su 1.6, 1.7, 8 e 9, e con i pacchetti di ore di assistenza facciamo esattamente questo lavoro: un audit della versione, del PHP e dei moduli del tuo negozio con una valutazione del rischio, l'aggiornamento all'ultima versione del tuo ramo se vuoi guadagnare tempo, e il piano di migrazione a PrestaShop 9 con l'inventario delle funzioni, i moduli sostitutivi e il lavoro sul tema. Le ore si consumano in base al lavoro reale, e puoi iniziare dall'audit e decidere dopo.