Moduli PrestaShop fermi alla 8: come capire se bloccano l'aggiornamento - init.d - sistemistica Linux, DevOps e sviluppo PrestaShop

# Moduli PrestaShop fermi alla 8: come capire se bloccano l'aggiornamento

Alessandro Corbelli~4 min
Table of Contents

Quando un negozio PrestaShop rimanda l'aggiornamento, quasi mai la colpa è del core. La frase che sentiamo più spesso è un'altra: "non possiamo aggiornare perché il modulo X non funziona con la versione nuova". Il modulo del gestionale, quello dei corrieri, quello comprato anni fa per gli sconti ai rivenditori.

È un problema reale, ma raramente è un vicolo cieco. In questo articolo vediamo come fare l'inventario dei moduli, come riconoscere quelli che bloccano davvero il passaggio a PrestaShop 9, e quali sono le tre strade per sbloccarli.

Perché un modulo smette di funzionare

Un modulo è un pezzo di codice che aggiunge funzioni a PrestaShop agganciandosi a dei punti previsti, gli hook, oppure sostituendo classi del core con gli override. Quando PrestaShop cambia versione principale, alcune di queste cose cambiano:

  • funzioni e classi vecchie vengono rimosse o riscritte;
  • pagine del back office passano a Symfony, e i moduli che le modificavano nel modo vecchio non trovano più il punto in cui agganciarsi;
  • cambia la versione minima di PHP, e il codice scritto per PHP 7 può dare errori su PHP 8.

Un modulo scritto seguendo le regole, con hook e API ufficiali, di solito richiede poco lavoro. Un modulo pieno di override e scorciatoie richiede molto di più. Ne abbiamo parlato nell'articolo su cosa cambia passando a PrestaShop 9.

L'inventario: tre domande per ogni modulo

Prima di tutto serve una lista. Dal back office, nella gestione dei moduli, si esportano o si copiano a mano tutti i moduli installati, attivi e non. Per ognuno servono tre risposte.

  1. Si usa ancora? Sembra banale, ma in un negozio con qualche anno di vita una parte dei moduli è installata per prova, sostituita da altro o legata a una campagna finita. Ogni modulo tolto è un problema in meno, e spesso anche qualche query in meno: i moduli dimenticati sono una delle cause tipiche di un PrestaShop lento.
  2. Chi lo mantiene? Il produttore esiste ancora e pubblica aggiornamenti? Ha già una versione per la 9? Sulla pagina del modulo, la compatibilità dichiarata è il primo indizio.
  3. È stato modificato? Un modulo comprato e poi corretto a mano da qualcuno non si può più aggiornare senza perdere le modifiche. Va saputo prima.

Le tre strade: aggiornare, sostituire, adeguare

Dalla lista escono tre gruppi.

Aggiornare. Il produttore ha già una versione compatibile con la 9: si aggiorna sulla copia di prova e si verifica. È il caso più comune e il più economico.

Sostituire. Il produttore ha abbandonato il modulo, ma esiste un'alternativa solida e aggiornata che fa la stessa cosa. Si migrano configurazioni e dati, quando servono, e si sostituisce. Costa un po' di lavoro una volta, ma toglie un problema per sempre.

Adeguare. Il modulo è unico, ed è il lavoro che facciamo nello sviluppo PrestaShop: scritto su misura, oppure fa una cosa che nessun'alternativa fa nel modo giusto. Allora si adegua il codice alle API della 9, lo si prova sulla copia e lo si documenta. Un esempio frequente: il modulo che collega PrestaShop al gestionale, scritto anni fa da un consulente che non c'è più. Funziona, ma usa due override e una funzione rimossa. Adeguarlo richiede di solito qualche ora, molto meno di riscriverlo.

Il caso del codice abbandonato

Un modulo senza manutenzione non è solo un ostacolo all'aggiornamento: è anche un rischio di sicurezza, perché le vulnerabilità scoperte non verranno corrette. È lo stesso problema delle dipendenze abbandonate nel software in generale, di cui abbiamo scritto parlando di pacchetti compromessi e catena di fornitura. Nell'inventario, un modulo abbandonato e ancora usato merita sempre una decisione esplicita: sostituirlo o prenderlo in carico.

E vale la pena ricordare che restare indietro ha un costo che cresce: lo abbiamo raccontato in quanto rischi restando su PrestaShop 1.7 o 8.

Come evitare che si ripeta

Due abitudini riducono molto il problema alla prossima versione:

  • niente modifiche a mano ai moduli comprati: se serve una funzione in più, si scrive un modulo separato che si aggancia a quello esistente;
  • codice su misura secondo le regole: hook e API ufficiali, override solo quando non c'è altro modo, tutto versionato e documentato. Una pipeline di rilascio che prova il modulo su una copia del negozio a ogni modifica fa il resto.

In sintesi

I moduli fermi alla 8 sono il vero motivo per cui molti negozi non passano a PrestaShop 9, ma quasi mai sono un ostacolo insormontabile. Si fa l'inventario, si tolgono quelli inutili, si aggiornano quelli che hanno una versione nuova, si sostituiscono quelli abbandonati e si adeguano quelli unici. Il lavoro vero si concentra su pochi moduli, e conviene saperlo prima di iniziare, con una stima per ciascuno.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent'anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli