«Ho visto che su Addons c’è il modulo che mi serve, costa 89 euro. Lo prendo, me lo installi e siamo a posto?» Me la sento dire quasi ogni mese, e quasi sempre da chi ha già provato quella strada due volte. La prima è andata bene. La seconda il modulo si è rotto con l’aggiornamento di PrestaShop, l’autore non rispondeva più e per una settimana il carrello ha smesso di calcolare le spedizioni.
Non sto dicendo che i moduli del marketplace siano da buttare: ne installo anch’io, quando sono la risposta giusta. Sto dicendo che la domanda «quanto costa un modulo» arriva troppo presto. Prima viene un’altra domanda, e qui provo a spiegare quale, come si sviluppa davvero un modulo PrestaShop e quando non serve svilupparne nessuno.
Che cos’è un modulo PrestaShop, detto senza gergo
PrestaShop è costruito per essere esteso senza essere riscritto. Nel codice ci sono dei punti di aggancio — si chiamano hook — che il negozio attraversa mentre lavora: quando mostra una scheda prodotto, quando aggiunge una riga al carrello, quando conferma un ordine. Un modulo è un pacchetto che si attacca a uno o più di quei punti e aggiunge un comportamento.
La conseguenza pratica è questa: un modulo scritto bene non modifica i file del negozio. Vive in una sua cartella, si attiva, si disattiva, si disinstalla, e se domani lo togli il negozio torna com’era. Un intervento fatto a mano sui file del core ti lascia invece un negozio che non puoi più aggiornare senza rompere qualcosa, e quel conto arriva tutto insieme il giorno della patch di sicurezza.
L’ordine giusto: prima il comportamento, poi il codice
Quando qualcuno mi scrive «mi serve un modulo», io faccio sempre lo stesso percorso, in questo ordine.
1. Scrivere il comportamento in una frase. Non «mi serve un modulo per il B2B», ma «i clienti con partita IVA registrati come rivenditori devono vedere i prezzi netti e poter ordinare solo per multipli di 6 pezzi». La prima frase si può risolvere in dieci modi diversi e costa dieci prezzi diversi. La seconda si può preventivare, sviluppare e collaudare.
2. Verificare se PrestaShop lo fa già. Succede più spesso di quanto si pensi. Gruppi di clienti, listini, regole di catalogo, declinazioni, lingue: molte cose che vengono chieste come «modulo» sono configurazioni che esistono già e che nessuno ha mai impostato. Un’ora di configurazione batte qualunque sviluppo.
3. Cercare se esiste un modulo serio. Serio vuol dire: compatibile con la tua versione, con un changelog pubblico, con un autore che ha aggiornato il pacchetto negli ultimi mesi. Se c’è, lo si compra: non c’è nessuna gloria nello scrivere da zero una lista desideri.
4. Guardare il costo di manutenzione, non il prezzo. Qui è dove quasi tutti sbagliano i conti. Un modulo da 89 euro che va rifatto a ogni passaggio di versione maggiore costa, su tre anni, più di un modulo su misura che conosci riga per riga. La domanda non è «quanto costa», è «chi lo aggiorna quando PrestaShop cambia».
5. Solo adesso, sviluppare. E svilupparlo in modo che si possa togliere: hook, nessun override dei file core, nessuna query scritta a mano dove esiste un metodo del framework, le stringhe traducibili, la configurazione in un pannello e non nel codice.
6. Collaudare su una copia, mai in produzione. Un modulo che tocca carrello, prezzi o checkout va provato su uno staging con dati veri — ordini, spedizioni, un pagamento di prova andato a buon fine — prima di arrivare sul negozio che incassa.
Cosa non funziona, e perché
Toccare i file del core. Funziona subito e ti blocca per sempre: il prossimo aggiornamento sovrascrive la modifica, oppure non lo installi più per paura. Se devi cambiare il comportamento di una classe PrestaShop ha gli override, e se stai per usare un override chiediti se non c’è un hook. Da chiedere prima di comprare, invece: la compatibilità dichiarata «1.7 / 8.x» a volte vuol dire «provato su 1.7.6».
Accumulare moduli gratuiti che si sovrappongono. Ho visto negozi con tre moduli che agivano sulla pagina prodotto, due dei quali facevano quasi la stessa cosa. Il risultato non è «più funzioni»: è un negozio che carica tre volte lo stesso JavaScript e un bug che nessuno riesce a isolare.
Far fare al tema il lavoro del modulo. Quando una funzione viene scritta dentro il template del tema, il giorno che cambi tema la perdi. E il tema si cambia più spesso di quanto si creda.
Mettere un modulo al posto di una decisione. Se le schede prodotto non convertono, un popup non risolve. Se il magazzino non è allineato, un modulo di disponibilità mostra un dato sbagliato con più grafica attorno.
Quanto costa, con i numeri veri
Nel mio catalogo i moduli PrestaShop su misura stanno tutti a 199 € (IVA esclusa), uno per funzione, perché un modulo che fa una cosa sola si collauda e si mantiene. Sono venti: tra gli altri i filtri prodotto avanzati, la ricerca istantanea, upsell e cross-sell, wholesale e prezzi B2B, la richiesta preventivo, il configuratore di prodotto, multilingua e multivaluta, fatture e documenti, il tracciamento ordini e gli sconti quantità con prezzi dinamici.
Attorno al modulo, quando serve, ci sono altre voci pubbliche: l’Audit SEO Tecnico a 190 € se il dubbio è se il problema sia il modulo o il sito; Turbo Boost E-commerce a 400 € quando il negozio è lento e si dà la colpa ai moduli; la manutenzione mensile a 90 €/mese, che è il modo di non ritrovarsi con tre versioni di arretrato; la sincronizzazione di anagrafiche, giacenze e prezzi col gestionale a 1.900 €, che è il lavoro vero dietro metà delle richieste che arrivano chiamandolo «modulo». E se non sai da quale parte iniziare, c’è la Call Strategica a 97 €: mezz’ora in cui ti dico anche che il modulo non ti serve, se è il caso.
Come lo sviluppo, in pratica
Parto dalla frase del punto 1 e la trasformo in un elenco di casi da verificare, compresi quelli che non devono accadere. Scelgo gli hook, scrivo il modulo, lo provo su una copia del negozio caso per caso, poi vado in produzione in un momento di traffico basso e resto a guardare gli ordini. Consegno il codice con la nota di quali hook usa: serve a chi verrà dopo di me per capire in due minuti cosa fa.
Il senso di tutto questo non è il modulo. È che il negozio resti aggiornabile, che ogni funzione si possa spegnere senza conseguenze e che tu sappia sempre quale pezzo fa cosa. Se ti interessa come ragiono sugli altri interventi, l’indice completo è nella guida ai servizi.
Domande che mi fanno spesso
Quanto tempo ci vuole per sviluppare un modulo PrestaShop?
Dipende da quanti punti del negozio tocca. Un comportamento in più sulla scheda prodotto o una vista nel back office è questione di giorni. Un modulo che entra nel carrello, nei prezzi o nel checkout richiede più collaudo che sviluppo, perché ogni combinazione di spedizione, imposta e sconto va provata. La parte che allunga i tempi non è quasi mai il codice: è arrivare alla descrizione precisa del comportamento.
Meglio un modulo del marketplace o uno su misura?
Un modulo del marketplace, se esiste, è compatibile con la tua versione e ha un autore che lo aggiorna. Su misura quando la funzione dipende dal tuo modo di lavorare — listini, multipli d’ordine, regole di sconto, documenti — perché lì il modulo generico ti costringe a cambiare il processo per adattarti al software, e non il contrario.
Un modulo su misura si rompe quando aggiorno PrestaShop?
Se è scritto sugli hook e senza toccare i file del core, un aggiornamento minore di norma non lo tocca. Un passaggio di versione maggiore va verificato sempre, modulo per modulo, su una copia del negozio. È per questo che conviene sapere quali hook usa ogni modulo installato: trasforma una giornata di panico in un controllo di mezz’ora.
Posso disinstallare un modulo senza perdere i dati?
Dipende da come è stato scritto. Un modulo fatto bene distingue la disattivazione — spegne la funzione e lascia tutto dov’è — dalla disinstallazione, che rimuove anche le sue tabelle. Prima di disinstallare qualsiasi cosa, un backup del database: vale per tutti i moduli, compresi quelli che non ho scritto io.