Copre PrestaShop dalla versione 1.5 alla 9.x, scritto dal team di mypresta.rocks. Trasparenza: siamo un fornitore di moduli PrestaShop, quindi gli standard tecnici qui sotto sono gli stessi che applichiamo al nostro codice.
Abbiamo pubblicato moduli PrestaShop per ogni versione dalla 1.5 alla 9.x, un decennio che attraversa l'era di Smarty e degli override, la riscrittura Symfony della 1.7, il consolidamento della 8.x e il presente della 9.x. È un periodo abbastanza lungo per smettere di tirare a indovinare. Quello che segue non è filosofia: è la lista breve delle decisioni tecniche che, con il senno di poi, hanno separato i moduli sopravvissuti a dieci anni di aggiornamenti da quelli trasformati in ticket di supporto. Ogni lezione qui è legata a qualcosa di specifico in PrestaShop, una directory, un hook, una chiave di configurazione, una classe, perché i consigli vaghi ("scrivi codice pulito") non aiutano nessuno. Quindi cosa ci guadagni? Se sviluppi o acquisti moduli, questi sono gli aspetti che decidono davvero se il tuo negozio resterà stabile al prossimo aggiornamento, e le domande che vale la pena fare prima che un modulo tocchi il tuo negozio.
Lezione 1: gli override sono un debito che paghi al momento dell'aggiornamento
PrestaShop include un sistema di override: inserisci un file in /override/classes/, /override/controllers/ o /override/modules/ e modifichi il comportamento del core senza cambiare i file del core. Sembra elegante. È la principale fonte dei ticket "il mio negozio si è rotto dopo aver installato un modulo" che abbiamo mai gestito.
Il meccanismo spiega il perché. Gli override vengono compilati nella cache dell'indice delle classi di PrestaShop, la cui posizione varia in base alla versione, per esempio cache/class_index.php nelle installazioni più vecchie dell'era 1.6. Due moduli che sovrascrivono entrambi Product o Cart non possono coesistere: il secondo che viene installato semplicemente fallisce o, peggio, prevale in silenzio e rompe il primo. Non esiste alcuna fusione automatica. E poiché l'override è una copia congelata di una classe del core, il giorno in cui aggiorni PrestaShop il tuo override estende ancora la firma del metodo vecchia, mentre il resto del core è andato avanti. È così che un negozio funzionante diventa una schermata bianca dopo un aggiornamento minore.
La nostra regola, imparata presto e mai più infranta: costruire esclusivamente con hook, API dei moduli e, su 1.7+, servizi Symfony, mai con la directory degli override. Se non puoi fare una cosa con un hook, la risposta onesta di solito è che quella cosa va fatta in modo diverso, non che dovresti ricorrere a un override. Quando valuti un modulo di terze parti, la domanda più utile da fare al fornitore è: "questo installa qualcosa in /override?" Un "no" vale più di qualunque lista di funzionalità. Approfondiamo i compromessi tecnici più ampi dello sviluppo su questa piattaforma nel nostro sguardo onesto sul perché abbiamo scelto PrestaShop.
Lezione 2: la retrocompatibilità è una decisione di design, non una patch
Un negozio che gira su PrestaShop 1.6 incassa denaro reale e serve clienti reali. La tentazione è scrivere solo per la versione corrente e dire a tutti gli altri di aggiornare, ma gli aggiornamenti sono progetti costosi e rischiosi che molti commercianti rimandano razionalmente per anni. Abbandonarli significa abbandonare un mercato pagante.
La lezione è che la compatibilità va progettata dalla prima riga, perché aggiungerla dopo è molto più difficile. In concreto, significa:
- Rilevare la versione invece di dare per scontato. Una semplice condizione version_compare(_PS_VERSION_, '1.7.0.0', '>=') nei punti in cui l'API diverge davvero (motore di template, classi base dei controller, il passaggio graduale dagli schemi legacy ObjectModel/AdminController verso controller Symfony, servizi, form e codice domain/CQRS) costa poche righe ed evita di dover mantenere un fork.
- Astrarre le parti che cambiano. Il salto dalla 1.6 alla 1.7 ha cambiato il modo in cui funzionano controller di amministrazione, template (.tpl Smarty vs Twig) e registrazione delle risorse. Incapsularli dietro un tuo piccolo helper significa un solo percorso di codice, non due basi di codice.
- Degradare con eleganza. Se una funzionalità dipende da qualcosa disponibile solo in 8.x+, rilevane l'assenza e usa un'alternativa, invece di generare un errore fatale su 1.6.
Questa è anche una promessa di compatibilità che facciamo nei testi e nel codice: il nostro codice dei moduli supporta PHP 7.1+ quando la versione di PrestaShop installata lo consente; PrestaShop 9.x richiede una versione moderna di PHP, e il motivo per cui un modulo che abbiamo scritto nel 2016 si installa ancora senza problemi oggi è che quelle condizioni erano presenti dal primo commit. Abbiamo raccontato la realtà tecnica del supporto a questa gamma di versioni in le sfide dello sviluppo di moduli PrestaShop.
Lezione 3: le prestazioni sono una funzionalità, e hanno un budget
Un modulo che aggiunge 200 ms a ogni pagina non sta aggiungendo una funzionalità: sta imponendo una tassa che il commerciante paga a ogni visita, su ogni pagina, per sempre. I negozi che restano veloci sono quelli i cui moduli rispettano un budget.
I punti specifici di PrestaShop in cui questo problema emerge, e come teniamo la linea:
- Hook eseguiti su ogni pagina. Un modulo agganciato a displayHeader viene eseguito sulla maggior parte dei caricamenti del front office, e actionDispatcher viene eseguito presto nel dispatch della richiesta. Se quell'hook svolge lavoro non necessario, una query al database, il rendering di un template, su pagine in cui la funzionalità è irrilevante, esci subito. La prima riga dell'hook dovrebbe verificare se quella pagina ne ha davvero bisogno e fare return in caso contrario. In pratica, è così:
Quel singolo controllo trasforma una tassa per pagina in un costo legato alla funzionalità. Lo stesso schema si applica ovunque un hook venga eseguito globalmente ma la funzionalità sia specifica di una pagina.public function hookDisplayHeader($params) { // Only the product page needs this widget – bail on every other page. if ($this->context->controller->php_self !== 'product') { return; } // ...the actual work runs only where it matters. } - Risorse caricate ovunque. Registrare CSS/JS globalmente tramite registerJavascript()/registerStylesheet() nell'hook actionFrontControllerSetMedia, invece di limitarli ai controller che li usano, appesantisce ogni pagina. Carica le risorse dove servono, e da nessun'altra parte.
- Query ripetute non in cache. I risultati che non cambiano tra una richiesta e l'altra devono stare nel livello Cache di PrestaShop, non essere recuperati a ogni caricamento. Combina questo con le cache del back office (Parametri avanzati → Prestazioni: cache Smarty, CCC per JS/CSS) per ottenere vantaggi cumulativi.
Il nostro standard operativo: un modulo dovrebbe aggiungere meno di circa 10 ms a una pagina quando non sta facendo attivamente qualcosa su quella pagina. Questo numero è un obiettivo che imponiamo a noi stessi, non una garanzia sul tuo negozio specifico: l'impatto reale dipende dal tuo hosting, dagli altri moduli e dal volume dei dati, e vale la pena misurarlo con il profiler di debug (_PS_DEBUG_PROFILING_, insieme a _PS_MODE_DEV_, su una copia di staging) invece di fidarsi delle affermazioni di qualsiasi fornitore, noi compresi.
Lezione 4: testa su negozi reali, non su installazioni pulite
Un modulo che funziona su un PrestaShop pulito con 10 prodotti demo e nessun altro modulo ha dimostrato pochissimo. I negozi reali hanno oltre 1.000 prodotti, 20-40 moduli attivi, un tema personalizzato o child, diverse lingue, in alcuni casi il multishop, e anni di dati accumulati su ordini e clienti. È lì che vivono le sorprese.
I problemi che solo un ambiente reale fa emergere sono concreti e prevedibili: SQL che va bene su 200 righe e va in timeout su 200.000; un hook che entra in conflitto con l'override di un altro modulo (vedi Lezione 1); una traduzione che si rompe perché una stringa è stata codificata direttamente invece di passare dall'API di traduzione; un contesto multishop in cui Shop::getContext() non è quello che avevi dato per scontato. Manteniamo copie di staging ripristinate dalla produzione proprio perché i clienti non diventino il banco di prova.
Lezione 5: l'ecosistema decide la tua stabilità più del core
In dieci anni abbiamo passato molto più tempo a diagnosticare problemi causati dai moduli di altre persone che dal core di PrestaShop. La matematica è spietata: l'affidabilità di un negozio è grosso modo l'affidabilità del suo modulo più debole, perché una sola estensione scritta male, un conflitto di override, un errore fatale in un hook, una query senza escaping. Può mettere fuori uso un negozio altrimenti sano.
Da questo sono nate due conclusioni pratiche. Primo, scriviamo in modo difensivo: controlliamo le condizioni che ci aspettiamo, gestiamo gli stati imprevisti invece di presumere che gli altri moduli si siano comportati bene, e non diamo mai per scontato che il contenuto di un hook abbia esattamente la forma suggerita dalla documentazione. Secondo, ed è quello che conta per i proprietari di negozi, la qualità dei moduli batte la quantità dei moduli, sempre. Trenta moduli economici sono trenta passività al prossimo aggiornamento; cinque moduli ben costruiti non lo sono. Abbiamo argomentato il caso completo in perché la qualità dei moduli conta più della quantità, il costo nascosto dietro il "gratis" in il vero costo dei moduli gratuiti, e come distinguere il buono dal cattivo prima dell'acquisto nella guida per acquirenti del Marketplace PrestaShop Addons.
Lezione 6: i ticket di supporto sono la tua tabella di marcia
Le migliori funzionalità che abbiamo mai rilasciato non sono nate da brainstorming interni: sono arrivate dalla casella del supporto. Il valore sta nel riconoscere gli schemi: quando più clienti fanno la stessa domanda, la documentazione non è chiara; quando più clienti chiedono la stessa cosa, il mercato ti sta dicendo cosa costruire; quando un bug compare su un negozio, è già latente su altri, solo che non te ne hanno ancora parlato.
È anche per questo che vendiamo con supporto diretto dagli sviluppatori, senza intermediari rivenditori. Non è solo un vantaggio per il cliente; è il nostro canale di ricerca prodotto. Un fornitore che esternalizza il supporto perde il segnale più ricco su ciò di cui il suo software ha davvero bisogno.
Lezione 7: semplice batte ingegnoso, ogni volta
Il codice ingegnoso è difficile da analizzare in debug alle 23 quando un negozio non è raggiungibile, difficile da passare al prossimo sviluppatore e difficile da ragionare quando la segnalazione del bug arriva finalmente sei mesi dopo. Abbiamo riscritto abbastanza del nostro primo codice troppo furbo da trattare la leggibilità come una funzionalità. Un approccio lineare che un junior può seguire vale più di uno elegante che richiede dieci minuti per essere decifrato, perché il costo del codice si paga soprattutto nella manutenzione, non nella scrittura.
Cosa faremmo diversamente
Il senno di poi è ingiustamente chiaro. Se ricominciassimo quei dieci anni:
- Adotteremmo prima i servizi Symfony e gli schemi moderni dei controller: nell'era AdminController abbiamo costruito pagine di amministrazione a mano che sono diventate costose da mantenere quando la piattaforma è andata avanti.
- Investiremmo nei test automatizzati dal primo anno, non dal terzo. Il costo di un test mancante lo paga un cliente, più tardi, nel momento peggiore.
- Standardizzeremmo prima il nostro framework per le interfacce di amministrazione. Troppi moduli iniziali avevano pagine di back office su misura; un toolkit interno condiviso avrebbe risparmiato anni di lavoro duplicato.
- Saremmo più aggressivi nel rimuovere funzionalità poco usate. Ogni caso limite mantenuto in vita è complessità portata avanti per sempre, e la complessità è il posto in cui si nascondono bug e rotture negli aggiornamenti.
Domande comuni sui moduli PrestaShop di lungo periodo
Qual è la domanda più utile da fare prima di acquistare un modulo?
"Questo installa qualcosa in /override?" Un "no" vale più di qualunque lista di funzionalità. Gli override vengono compilati nell'indice delle classi di PrestaShop, non possono essere uniti quando due moduli toccano la stessa classe del core, e congelano una copia di un metodo del core che si rompe il giorno in cui aggiorni. Un modulo costruito su hook, API dei moduli e, su 1.7+, servizi Symfony si aggancia senza modificare il core e sopravvive ad aggiornamenti per cui non era stato cablato esplicitamente. Quella singola risposta dice più cose sulla stabilità a lungo termine di quante ne dicano gli screenshot.
Quanto impatto sulle prestazioni dovrebbe aggiungere un modulo ben costruito?
Il nostro standard operativo è meno di circa 10 ms su una pagina quando il modulo non sta facendo attivamente qualcosa su quella pagina: lo otteniamo con hook che escono subito, risorse limitate ai controller che le usano (non registrate globalmente) e query ripetute messe in cache invece di essere recuperate di nuovo. Questo numero è un obiettivo che imponiamo a noi stessi, non una garanzia sul tuo negozio: l'impatto reale dipende dal tuo hosting, dagli altri moduli e dal volume dei dati. Misuralo tu stesso con il profiler di debug (_PS_DEBUG_PROFILING_ insieme a _PS_MODE_DEV_) su una copia di staging invece di fidarti delle affermazioni di qualsiasi fornitore, noi compresi.
Perché la qualità di un modulo conta più del numero di moduli che ho?
Perché l'affidabilità di un negozio è grosso modo l'affidabilità del suo modulo più debole: una sola estensione scritta male (un conflitto di override, un errore fatale in un hook, una query senza escaping) può mettere fuori uso un negozio altrimenti sano. Trenta moduli economici sono trenta passività al prossimo aggiornamento; cinque moduli ben costruiti non lo sono. In dieci anni abbiamo passato molto più tempo a diagnosticare problemi causati dai moduli di altre persone che dal core di PrestaShop, ed è per questo che sosteniamo che la qualità batte sempre la quantità: il ragionamento completo è in perché la qualità dei moduli conta più della quantità.
Un modulo scritto anni fa può davvero funzionare ancora su PrestaShop 9?
Sì, se la retrocompatibilità è stata progettata dalla prima riga invece di essere aggiunta dopo. Significa rilevare la versione nei punti in cui l'API diverge davvero (version_compare(_PS_VERSION_, '1.7.0.0', '>=')), astrarre le parti che cambiano (Smarty vs Twig, AdminController vs controller Symfony, registrazione delle risorse) dietro un proprio piccolo helper così da avere un solo percorso di codice e non due basi di codice, e degradare con eleganza quando una funzionalità dipende da qualcosa esposto solo dalle versioni più recenti. I moduli che abbiamo scritto nel 2016 si installano ancora senza problemi nel 2026 perché quelle condizioni erano presenti dal primo commit.
Cosa non è mai cambiato
PrestaShop è cambiato enormemente in questi dieci anni: da Smarty a Twig, la migrazione a Symfony, la ricostruzione dalla 1.6 alla 1.7, le linee 8.x e 9.x. I principi no:
| Principio | Cosa significa in pratica su PrestaShop |
|---|---|
| Niente override, mai | Solo hook, API dei moduli e servizi Symfony, niente in /override. |
| Le prestazioni non sono negoziabili | Hook con uscita anticipata, risorse circoscritte, query ripetute in cache, un vero budget in ms. |
| La retrocompatibilità è una promessa | Rilevare la versione e astrarre le parti che cambiano dalla prima riga, supporto dalla 1.6 alla 9. |
| Ascolta i clienti più dei concorrenti | La casella del supporto è la tabella di marcia; il supporto diretto dagli sviluppatori mantiene intatto quel segnale. |
| Semplice batte ingegnoso | La leggibilità è una funzionalità; la manutenzione è dove vive il costo. |
| Testa su negozi reali | Staging modellato sulla produzione: volume di dati reale, insieme di moduli reale, temi reali. |
Il filo conduttore è la responsabilità sul proprio software. Nessuna di queste lezioni ha senso su una piattaforma in cui non puoi vedere il codice, la scelta override-o-no non spetta a te e "il prossimo aggiornamento" è qualcosa che un fornitore ti impone secondo i suoi tempi. Sono lezioni da open source, ed è esattamente per questo che continuiamo a scegliere di costruire qui: una scelta che esaminiamo in perché possedere il tuo codice conta più che mai e confrontiamo con l'alternativa delle piattaforme in affitto in PrestaShop vs Shopify: un negozio che possiedi o un negozio che affitti. Dopo dieci anni, i moduli che abbiamo scritto nel 2016 funzionano ancora nel 2026: non perché PrestaShop sia rimasto fermo, ma perché questi sei principi ci hanno indicato cosa costruire perché durassero.
Continua a leggere
- Perché la qualità dei moduli batte la quantità, la versione della Lezione 5 per chi possiede un negozio.
- Perché possedere il tuo codice conta, il filo della responsabilità dietro ogni lezione qui.
- PrestaShop vs Magento, perché una piattaforma snella e basata su hook resta manutenibile dove una più pesante non ci riesce.
