Il vero costo dei moduli gratuiti: cosa ottieni quando non paghi nulla

I controlli e le fonti degli avvisi indicati sotto sono aggiornati per PrestaShop 1.6, 1.7, 8.x e per la linea 9.0–9.1. Sviluppiamo e vendiamo moduli PrestaShop e gestiamo anche negozi nostri, quindi abbiamo un interesse diretto in questo dibattito; i controlli qui sotto funzionano allo stesso modo che il modulo sia nostro, di un concorrente o gratuito.

Zero è il prezzo più ingannevole nel software e-commerce. Un modulo gratuito non costa nulla da scaricare, poi presenta il conto lentamente: nei fine settimana di aggiornamento che prendono una brutta piega, in una procedura di acquisto che si rompe di sabato senza nessuno da chiamare, in un back office che diventa 300 ms più lento a ogni installazione che nessuno ha verificato. Dopo oltre dieci anni passati a sistemare negozi PrestaShop, possiamo dirti da dove arrivano le emergenze ricorrenti: una quota importante dei bug critici, degli incidenti di sicurezza e degli aggiornamenti falliti che ci troviamo a districare nasce da un modulo installato proprio perché era gratuito. Non perché il gratuito sia sbagliato di per sé, alcuni moduli gratuiti sono eccellenti, e ti indicheremo quelli validi, ma perché l'economia del "gratis" produce una serie prevedibile di problemi su una piattaforma che cambia con la frequenza di PrestaShop.

Questo articolo parla di quel conto specifico: cosa paghi davvero quando non paghi nulla, in termini PrestaShop. Se la tua domanda è più ampia, come distinguere un modulo di qualità da un rischio, a prescindere dal prezzo. Quello è un tema a parte, trattato in perché la qualità dei moduli conta più della quantità e nella guida all'acquisto sul marketplace PrestaShop Addons. Qui restiamo sulla questione del prezzo: gratis, e tutto ciò che si porta dietro.

Perché esiste il "gratuito", e quanto ti costa ogni tipo

"Gratuito" non significa una cosa sola. Prima di valutare il rischio, capisci quale tipo di gratuito hai davanti, perché la motivazione dietro un modulo anticipa il modo in cui invecchierà sul tuo negozio.

E quindi? Il "gratuito" che vuoi è quello ufficiale o open source mantenuto attivamente. Il "gratuito" che costa di più in silenzio è l'ex modulo a pagamento abbandonato: è quello che più probabilmente porta con sé sia una vulnerabilità nota sia una dipendenza rigida da una versione PrestaShop che stai per lasciarti alle spalle.

I cinque costi nascosti, in termini PrestaShop

1. Sicurezza, e PrestaShop pubblica le prove

Questo è il punto che può chiudere un negozio, non solo infastidirlo. Gli sviluppatori di moduli a pagamento hanno un motivo commerciale per correggere in fretta: reputazione e rinnovi dipendono da questo. Un modulo gratuito abbandonato non ha nessuno dall'altra parte. L'ecosistema PrestaShop lo documenta pubblicamente: il database degli avvisi di sicurezza Friends of Presta (security.friendsofpresta.org) e gli avvisi di sicurezza GitHub di PrestaShop elencano per nome le CVE a livello di modulo, e una quota sorprendente delle voci su SQL injection riguarda moduli gratuiti o abbandonati i cui front controller concatenavano $_GET direttamente in una query invece di usare Db::getInstance()->escape() o pSQL().

L'esposizione pratica su PrestaShop è concreta: il front controller di un modulo vulnerabile (qualsiasi cosa sotto modules/<name>/controllers/front/) è raggiungibile via URL, che tu usi o meno quella funzione. Un solo parametro non sanificato lì può leggere le tabelle ps_customer, ps_address e ps_orders: nomi, email, indirizzi, cronologia ordini. Prima di installare qualsiasi cosa, cerca il nome del modulo in quei database di avvisi. Richiede due minuti ed è il controllo con il valore più alto che puoi fare.

2. Compatibilità. L'aggiornamento è dove muoiono i moduli gratuiti

PrestaShop si muove. Tra 1.6, 1.7, 8 e le attuali 9.0–9.1, la piattaforma ha cambiato nomi di hook, migrato parti del back office e dell'architettura core a Symfony/Twig, mentre il front office continua a basarsi su temi e template Smarty, ha deprecato metodi dei controller e modificato lo schema del database. Ogni modulo richiede lavoro continuo per restare al passo. I moduli a pagamento lo finanziano; quelli gratuiti mantenuti da volontari spesso no.

Lo schema di rottura è così costante che possiamo prevederlo: un modulo gratuito installato su 1.7 genera errori fatali dopo il passaggio a 8 o 9 perché chiama ancora un metodo rimosso, oppure registra o chiama hook/API il cui comportamento o contesto è cambiato, oppure dipende da metodi core rimossi/deprecati, oppure include un .tpl per il vecchio front office Smarty. Te ne accorgi in tre punti: un 500 sul front office, una schermata bianca in Moduli > Gestione moduli, o una rottura silenziosa in cui l'hook semplicemente non viene mai renderizzato. A quel punto le scelte sono: trovare un sostituto, pagare qualcuno per portare il codice, oppure bloccare il negozio su una vecchia versione PrestaShop sempre meno sicura. Tutte e tre costano più di quanto sarebbe costato un modulo mantenuto. (Questo è anche il motivo per cui la preparazione agli aggiornamenti è una questione di strategia di piattaforma, non solo di moduli: analizziamo i compromessi più ampi in perché abbiamo scelto PrestaShop.)

Un'abitudine difensiva che non costa nulla: un modulo pensato per sopravvivere ai cambi di versione di PrestaShop protegge le proprie chiamate invece di dare per scontato che un metodo esista. Vista dall'altro lato, la stessa protezione ti permette di fare un controllo di buon senso sul modulo: se il codice chiama metodi core senza condizioni, quella è la riga che causerà un errore fatale sulla versione che li ha rimossi.

// What version-aware module code looks like – and the absence of this
// is what produces the post-upgrade 500. PrestaShop exposes its own
// version, so a careful module checks before it calls:
if (version_compare(_PS_VERSION_, '8.0.0', '>=')) {
    // 8.x / 9.x code path
} else {
    // 1.7.x fallback
}

// Guard a method that may not exist on the running core, rather
// than calling it blindly and fataling on the version that removed it:
if (method_exists('SomeCoreClass', 'someMethod')) {
    SomeCoreClass::someMethod();
}

3. Supporto, il team di supporto sei tu

Gratuito significa nessun obbligo di supporto, e quella clausola fa molto lavoro. Quando il modulo si comporta male, le opzioni sono uno scarno readme.md, un thread sul forum sperando che qualcuno risponda, oppure leggere il sorgente da solo. Per il titolare di un negozio che non è uno sviluppatore, "gratuito" si trasforma allora nella fattura di un freelance chiamato a fare debug: spesso a una tariffa oraria che, dopo uno o due incidenti, supera il costo pieno di un modulo a pagamento supportato. La cosa che hai preso senza pagare ti sta fatturando a ore, solo tramite un'altra persona.

4. Prestazioni, il costo che non vedi finché non fai profiling

I moduli gratuiti vengono distribuiti senza la pressione di revisione del codice e feedback dei clienti che intercetta il codice lento, quindi hanno statisticamente più probabilità di portarsi dietro i classici peccati di prestazioni in PrestaShop:

• Query dentro i cicli. Un modulo che esegue una query Db per prodotto su una pagina categoria da 50 prodotti genera 50 query dove basterebbe un JOIN: lo vedi nel profiler di debug in Parametri avanzati > Prestazioni e in SHOW PROCESSLIST sotto carico.
• Hook registrati in eccesso. Agganciarsi a displayHeader, displayFooter e actionFrontControllerSetMedia quando la funzione ne richiede uno solo significa che il codice viene eseguito su ogni pagina, comprese quelle in cui non fa nulla.
• Nessuna cache. Ricalcolare gli stessi dati a ogni richiesta invece di usare Cache o una tabella: accettabile in una demo, costoso con traffico reale.
• Abuso di override. È il caso peggiore, ed è specifico di PrestaShop: vedi sotto.

[SCREENSHOT: piè di pagina del profiler di debug PrestaShop (abilita la modalità debug, poi carica una pagina del front office) che mostra il conteggio delle query e la suddivisione dei tempi di caricamento per pagina. Un modulo che esegue query dentro un ciclo compare qui con un conteggio query che cresce insieme al numero di prodotti nella pagina.]

Un singolo modulo gratuito scritto con poca cura può aggiungere alcune centinaia di millisecondi al time-to-first-byte. Siamo volutamente prudenti sulla cifra esatta, dipende interamente dal modulo e dal tuo traffico, ma la direzione non è in discussione, e pagine più lente ti costano sia in conversioni sia nei segnali di esperienza pagina valutati dai motori di ricerca. Se il sintomo è il carico dei moduli, lezioni da 10 anni di sviluppo PrestaShop approfondisce cosa sposta davvero l'ago.

5. La trappola degli override, il killer silenzioso dei moduli gratuiti PrestaShop

Questo punto merita un titolo proprio perché è qui che i moduli gratuiti PrestaShop fanno danni che non noterai finché non sarà troppo tardi. PrestaShop permette a un modulo di depositare override di classi in /override/classes/ e /override/controllers/, con una cache generata della mappa classi (cache/class_index.php, oppure var/cache/<env>/class_index.php su 1.7+) che dice al core quali override caricare. Un modulo ben costruito usa gli hook e tocca gli override con parsimonia; uno gratuito costruito in fretta sovrascrive intere classi core. Le conseguenze sono specifiche:

• Due moduli non possono sovrascrivere lo stesso metodo. Installa un secondo modulo che sovrascrive Product::getPrice() e la seconda installazione fallisce in silenzio o schiaccia la prima: un conflitto che emerge come "la funzione semplicemente non va", senza errore.
• Gli override bloccano l'aggiornamento del core. 1-Click Upgrade e la migrazione Symfony si inceppano sugli override in conflitto; finisci per riconciliare manualmente i file prima di poter cambiare versione.
• La disinstallazione non pulisce sempre tutto. L'uninstall() di un modulo approssimativo lascia indietro file di override orfani, quindi l'ombra di un modulo rimosso mesi fa continua a essere eseguita su ogni pagina.

E quindi? I conflitti tra override sono la causa più comune per cui un negozio PrestaShop si rompe "misteriosamente" dopo aver impilato alcuni moduli gratuiti, e restano invisibili finché non vai a cercarli in /override/ e /var/cache/. È l'argomento più forte a favore del possesso e della comprensione del codice che gira sul tuo negozio, il caso più ampio trattato in e-commerce open source: perché possedere il tuo codice conta più che mai.

Verificare cosa c'è già sul tuo negozio, in sola lettura

Se su un negozio ereditato o costruito negli anni si sono già accumulati moduli gratuiti, non devi andare a intuito. Alcuni controlli sicuri fanno emergere le tre cose che fanno male: override orfani, moduli disattivati ma ancora presenti e file fantasma di override sopravvissuti a una disinstallazione. Nulla di tutto questo modifica qualcosa: è tutto in sola lettura.

Prima, i file di override che vivono davvero su disco. Non esiste una tabella database per questi, quindi controlla il filesystem sotto la root del negozio (via SSH o tramite il file manager del tuo hosting):

# Every core class/controller something has overridden.
# Empty output is the healthy result.
find override/classes override/controllers -name '*.php' -not -name 'index.php' 2>/dev/null

# Cross-check: which overrides the core actually loads (1.7+).
# Files on disk that AREN'T in here are the orphaned ghosts.
grep -o "'[A-Za-z]*' =>" var/cache/prod/class_index.php 2>/dev/null | sort -u

Poi, dal database (esegui in Parametri avanzati → Gestore SQL, sola lettura, nessuna scrittura), elenca ogni modulo installato e verifica se è davvero abilitato. Le righe disabilitate che hanno ancora file su disco sono comuni, e i front controller di un modulo disabilitato possono comunque essere raggiungibili via URL:

SELECT name, version, active
FROM ps_module
ORDER BY active ASC, name;

Un file di override su disco che non è referenziato in class_index.php, oppure un modulo disattivato la cui cartella si trova ancora in modules/, è esattamente il tipo di residuo che gira su ogni pagina o nasconde una vulnerabilità nota. Una volta che li vedi, rimuoverli diventa una decisione invece di un mistero.

Quando il gratuito è la scelta giusta

Niente di tutto questo significa "non installare mai un modulo gratuito". Significa installare quelli giusti con gli occhi aperti. Il gratuito è davvero la scelta corretta quando:

• È ufficiale. I moduli inclusi in PrestaShop o pubblicati dal team PrestaShop (quelli con prefisso ps_: ps_searchbar, ps_emailsubscription, ps_facetedsearch) sono mantenuti come parte della piattaforma e testati su ogni release.
• Il progetto open source è vivo. Apri il repository GitHub e controlla il polso: commit recenti, più di un contributore, issue che ricevono risposta, release etichettate per le versioni PrestaShop attuali. Un repository sano è un segnale affidabile.
• Fa una sola cosa piccola. Un modulo che aggiunge un singolo campo o modifica una sola visualizzazione ha una superficie di bug molto minore rispetto a una suite "tuttofare". Piccolo e focalizzato invecchia meglio.
• È stato recensito di recente. Sul marketplace Addons, leggi le recensioni più nuove, non la media complessiva: un modulo che meritava cinque stelle nel 2021 oggi potrebbe accumulare recensioni da una stella con "si è rotto su 8.x".

La checklist prima dell'installazione (gratuito o a pagamento)

Passa ogni modulo, inclusi quelli a pagamento, attraverso questi controlli prima che tocchi il tuo negozio:

• Data dell'ultimo aggiornamento. Niente che non sia stato toccato da oltre un anno. Controlla prima, non dopo.
• Compatibilità di versione esplicita. "Funziona con 1.7+" non significa "funziona con 9". Pretendi che sia indicata la versione reale e confrontala con la tua installazione in Parametri avanzati > Informazioni.
• Avvisi di sicurezza. Cerca il nome del modulo su security.friendsofpresta.org e negli avvisi GitHub di PrestaShop.
• Impronta degli override. Scompatta il modulo e guarda in override/. Override su Product, Cart, Order o FrontController sono un segnale giallo: chiediti se gli hook avrebbero potuto fare lo stesso lavoro.
• Igiene delle query. Se sai leggere PHP, usa grep sui controller per cercare $_GET/$_POST grezzi dentro stringhe SQL senza pSQL() o cast (int). È lo schema classico della SQL injection.
• Prima backup, su una copia di staging. Database e file. Prova l'installazione su un clone, non sul sito in produzione. Se si rompe, ripristini invece di spiegare ai clienti perché il negozio è fermo.

La matematica reale del gratuito rispetto al pagamento

Togli la filosofia e resta un problema aritmetico. Un modulo gratuito si rompe durante un aggiornamento. Tu, o il freelance che assumi, passate un pomeriggio a diagnosticare un conflitto di override, portare un hook deprecato e ritestare la procedura di acquisto. Applica a quel pomeriggio qualsiasi tariffa oraria locale realistica e il modulo "gratuito" è già costato più di quanto sarebbe costato un modulo a pagamento mantenuto, in un solo incidente; e questi incidenti si ripetono ogni volta che PrestaShop rilascia una versione principale. Non citiamo volutamente una cifra in dollari, perché dipende dalla tariffa del tuo sviluppatore e da quanto male si è rotto il modulo; fai i conti con i tuoi numeri. La conclusione resta valida qualunque valore inserisci.

Quando confronti un modulo a pagamento con uno gratuito, verifica la licenza effettiva, il periodo degli aggiornamenti e le condizioni di assistenza. Il solo prezzo d’acquisto non indica quale aiuto sarà disponibile in seguito. Su mypresta.rocks i moduli premium includono tre mesi di assistenza e aggiornamenti. Sono disponibili estensioni a pagamento e la licenza del modulo continua dopo la fine dell’assistenza. I moduli gratuiti non includono assistenza gratuita. Accogliamo le segnalazioni di bug da tutti perché ci aiutano a migliorare il codice.

FAQ

Come verifico se un modulo gratuito ha vulnerabilità di sicurezza note?

Cerca il nome tecnico del modulo (il nome della sua cartella, ad esempio somemodule) nel database degli avvisi Friends of Presta su security.friendsofpresta.org e negli avvisi di sicurezza GitHub di PrestaShop prima di installarlo. Le CVE a livello di modulo sono elencate lì per nome, e una quota consistente delle voci su SQL injection riguarda moduli gratuiti o abbandonati. È un controllo da due minuti ed è quello con il valore più alto che puoi fare, perché un front controller vulnerabile sotto modules/<name>/controllers/front/ è raggiungibile via URL, che tu usi o meno quella funzione.

Un modulo gratuito si è rotto dopo l'aggiornamento di PrestaShop: quali sono le opzioni reali?

Tre, e tutte costano più di quanto sarebbe costato un modulo mantenuto: trovare un sostituto che supporti la nuova versione, pagare uno sviluppatore per portare il codice del modulo rotto, oppure congelare il negozio sulla vecchia versione PrestaShop (che ti lascia su una piattaforma sempre meno sicura: non è davvero un'opzione a lungo). Il problema di solito è un metodo core rimosso, un hook cambiato o un vecchio .tpl Smarty, e si presenta come un 500 sul front office, una Gestione moduli vuota o un hook che in silenzio non viene mai renderizzato. La lezione è a monte: controlla la compatibilità di versione esplicita prima dell'aggiornamento, non dopo.

Come capisco se un modulo usa override, e perché è importante?

Scompatta il modulo e guarda nella sua cartella override/ prima di installarlo. File sotto override/classes/ o override/controllers/, soprattutto se toccano Product, Cart, Order o FrontController, sono un segnale giallo. È importante perché due moduli non possono sovrascrivere lo stesso metodo (il secondo fallisce in silenzio o schiaccia il primo), gli override bloccano 1-Click Upgrade e una disinstallazione approssimativa lascia file di override orfani in esecuzione su ogni pagina. Su un negozio esistente, confronta i file su disco con var/cache/prod/class_index.php per trovare gli orfani.

I moduli ufficiali ps_ sono affidabili?

Sì, i moduli con prefisso ps_ inclusi in PrestaShop o pubblicati dal team PrestaShop (ps_searchbar, ps_emailsubscription, ps_facetedsearch e simili) sono mantenuti come parte della piattaforma e testati su ogni release. Sono il caso più chiaro in cui "gratis è la risposta giusta". Nota che parliamo specificamente dei moduli ufficiali inclusi, non dei moduli gratuiti in generale: il fatto che un modulo della community sia gratuito, da solo, non dice nulla sulla sua manutenzione.

Pagare un modulo è sempre meglio che usarne uno gratuito?

No, e se lo dicessimo staremmo solo cercando di venderti qualcosa. Il gratuito è davvero corretto per i moduli ufficiali ps_, per un progetto open source sano (commit recenti, più contributori, release etichettate per le versioni attuali) e per un piccolo modulo che fa una cosa mirata. La regola onesta non è "a pagamento batte gratuito": è "mantenuto batte abbandonato". Quello che paghi in un buon modulo a pagamento sono i prossimi anni di patch di compatibilità, una risposta di sicurezza quando arriva un avviso e qualcuno che risponde quando si rompe; dove un modulo gratuito offre già una manutenzione equivalente, quello gratuito è la scelta giusta.