La scheda di valutazione del rischio dei moduli: 12 controlli prima di installare

Non è necessario saper leggere il PHP per capire se un modulo PrestaShop può essere installato in sicurezza sul Suo negozio in produzione. La maggior parte dei danni provocati da un modulo difettoso è visibile da un browser e dal Suo back office, se sa dove guardare. Questa è la checklist che usiamo noi, scritta perché un titolare di negozio possa applicarla senza uno sviluppatore.

L'idea è semplice. Un modulo è codice non isolato che gira con tutti i privilegi del Suo negozio: può caricare risorse su ogni pagina, scrivere nel Suo database, modificare il comportamento del core e contattare altri server. Perciò, invece di fidarsi della pagina di vendita, Lei osserva ciò che il modulo fa davvero su una copia sicura del Suo negozio e gli assegna un punteggio. Dieci spunte verdi su dodici indicano un modulo che può installare con fiducia. Ma il punteggio non è tutta la storia: alcune righe sono limiti invalicabili. Una bandiera rossa sul checkout o sui dati dei clienti, sul test di reversibilità, su un nuovo dominio esterno o su override non dichiarati significa che il modulo resta fuori dal Suo negozio in produzione finché il fornitore non fornisce una spiegazione, qualunque cosa dicano le altre righe.

Esegua tutto questo prima su una copia di staging, mai in produzione. Duplichi il Suo negozio (la maggior parte degli host offre una clonazione di staging con un clic), oppure usi un'installazione usa e getta con il Suo tema e i Suoi altri moduli presenti. Vuole che il modulo affronti la stessa realtà disordinata del Suo negozio reale: il Suo tema, la Sua configurazione di lingua e valuta, i Suoi moduli esistenti, le Sue versioni di PrestaShop e PHP. Un modulo che si comporta bene solo su un'installazione vuota Le sta dicendo qualcosa.

Le dodici verifiche

1. Domini esterni e CDN

Come eseguirla: apra la homepage del Suo negozio, non la pagina delle impostazioni del modulo, nel browser, prema F12 per aprire gli Strumenti per sviluppatori, faccia clic sulla scheda Network e ricarichi la pagina. Ordini per dominio. Annoti ogni dominio che non è Suo. Ora installi il modulo e ricarichi di nuovo. È comparso qualche nuovo dominio di terze parti?

Superata: nessun nuovo dominio esterno sulle pagine che non usano la funzione. Modalità di fallimento: è esattamente la trappola descritta nel nostro saggio: un modulo che carica un font, uno script o un tracker dal server di qualcun altro su ogni pagina, aggiungendo ricerche DNS, peso, un'esposizione della privacy e una dipendenza da un server che Lei non controlla. Se un giorno quel server è lento o non risponde, il rendering della Sua vetrina può bloccarsi o peggiorare con esso.

Se preferisce contarli esattamente anziché leggere l'elenco a occhio, incolli questo nella stessa scheda Console degli Strumenti per sviluppatori e prema Invio: elenca ogni dominio che non è Suo e quante richieste ciascuno ha effettuato:

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource')) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

Conta ogni host che non è il Suo dominio principale, comprese eventuali sottodomini CDN gestiti da Lei stesso, che può tranquillamente ignorare. Lo esegua prima di installare il modulo, poi di nuovo dopo: qualsiasi host realmente nuovo è una nuova terza parte da cui la Sua vetrina ora dipende.

Questa è la verifica di maggior valore dell'elenco, perché intercetta esattamente il difetto descritto nel nostro saggio: un modulo che aggiunge in sordina un dominio di terze parti a ogni pagina. Se qui compare un host che Lei non ha aggiunto di proposito, si fermi e chieda al fornitore il perché prima che raggiunga il Suo negozio in produzione.

2. Risorse globali del front office

Come eseguirla: nella stessa scheda Network, filtri per CSS e JS e confronti il conteggio sulla Sua homepage prima e dopo l'installazione. Poi controlli una pagina che il modulo dovrebbe interessare e una che non dovrebbe.

Superata: i fogli di stile e gli script del modulo si caricano solo sulle pagine che li usano. Modalità di fallimento: un modulo "piccolo" che registra le proprie risorse su un hook globale dell'header aggiunge peso a ogni pagina del negozio, checkout compreso, per una funzione che vive in un solo punto. Moltiplichi tutto questo per una dozzina di moduli trascurati e otterrà un negozio lento senza un unico colpevole.

3. Override

Come eseguirla: prima di installare, guardi nella cartella /override del Suo negozio tramite FTP o il gestore file del Suo host (deve solo verificare se compaiono file, non è necessario leggerli). Installi il modulo, poi guardi di nuovo.

Superata: nessun nuovo file è comparso in /override (una cartella standard contiene già file segnaposto index.php: Lei cerca quelli nuovi). Modalità di fallimento: gli override risiedono in /override e cambiano il comportamento delle classi e dei controller del core di PrestaShop. Due moduli che sovrascrivono la stessa classe entrano in conflitto e, cosa cruciale, un override lasciato indietro dopo la disinstallazione è una delle cause principali del "il mio negozio si è rotto e disattivare le cose non ha risolto". I moduli ben fatti usano hook e servizi anziché sovrascrivere il core.

4. Hook utilizzati

Come eseguirla: nel back office, vada su Design › Posizioni (la schermata degli hook) e osservi dove il modulo si è registrato. Di solito può anche vedere gli hook di un modulo sulla sua pagina di configurazione.

Superata: gli hook corrispondono alla funzione. Un modulo di spedizione si aggancia alla spedizione e al checkout; un modulo di scheda prodotto si aggancia alla pagina del prodotto. Modalità di fallimento: un modulo agganciato a ogni pagina — displayHeader, displayFooter su tutto — "per sicurezza", quando la sua funzione compare in un solo punto. Ognuno di quegli hook è codice che gira a ogni caricamento di pagina.

5. Modifiche allo schema del database

Come eseguirla: nello strumento database del Suo host (phpMyAdmin o simile), annoti il numero di tabelle prima di installare. Installi e guardi cosa è stato aggiunto: sta controllando i nomi, non i contenuti.

Superata: le nuove tabelle hanno un namespace chiaro riferito al modulo (un prefisso riconoscibile) e, idealmente, sono documentate. Una manciata di tabelle ben denominate è del tutto normale e va bene. Modalità di fallimento: un modulo che sparge tabelle senza etichetta, o che scrive nelle tabelle del core di PrestaShop in modi che non dichiara, è un modulo su cui non potrà ragionare in modo pulito in seguito.

Se ha accesso al database (phpMyAdmin o la riga di comando), può elencare esattamente ciò che un modulo ha aggiunto. Annoti l'elenco prima di installare, poi lo esegua di nuovo dopo e confronti:

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables — list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

Un elenco breve e con prefisso chiaro è un buon segno. Uno sparpagliamento di tabelle senza etichetta — o scritture non dichiarate nelle tabelle del core come ps_orders o ps_customer — è ciò a cui deve prestare attenzione. (ps_ è il prefisso di tabella predefinito; sostituisca il Suo se lo ha cambiato e usi il nome tecnico del modulo al posto di mymodule.)

6. Pulizia alla disinstallazione

Come eseguirla: dopo la verifica dello schema, disinstalli il modulo e guardi di nuovo il database. Cosa ha rimosso e cosa ha lasciato?

Superata: il modulo rimuove ciò che ha creato — oppure dichiara chiaramente nella sua documentazione cosa conserva deliberatamente e perché (conservare le Sue impostazioni per una futura reinstallazione è una scelta legittima, se dichiarata). Modalità di fallimento: residui silenziosi. Tabelle orfane, righe di configurazione e file obsoleti che si accumulano ogni volta che prova un modulo. È la riga in cui il "tanto lo disinstallo" fallisce senza far rumore.

7. Job cron e webhook

Come eseguirla: controlli la documentazione e la pagina di configurazione del modulo per qualsiasi cosa venga eseguita a intervalli programmati o contatti un servizio esterno in background — sincronizzazioni, feed, attività di pulizia, integrazioni "collega il tuo account".

Superata: i job in background sono dichiarati e Lei può disattivarli. Modalità di fallimento: attività in background non dichiarate — un'attività che martella il Suo database a intervalli programmati, o un webhook che spedisce i Suoi dati da qualche parte senza che Lei se ne accorga. Non può gestire ciò che non sa essere in esecuzione.

8. Punti di contatto con checkout, ordini e dati dei clienti

Come eseguirla: con il modulo installato su staging, effettui un ordine di prova completo dall'inizio alla fine. Cerchi un prodotto. Apra una pagina prodotto. Apra le principali schermate del back office. Funziona ancora tutto esattamente come prima?

Superata: checkout, ricerca, pagine prodotto e amministrazione non subiscono alterazioni, a meno che non sia letteralmente il compito del modulo. Modalità di fallimento: un modulo che tocca il flusso d'ordine o i dati dei clienti tocca il Suo fatturato e i Suoi obblighi di conformità. Un checkout che si rompe — o che calcola male in silenzio — Le costa denaro reale il giorno in cui va in produzione, non in un laboratorio.

9. Multinegozio, lingua e valuta

Come eseguirla: se gestisce più di un negozio, più di una lingua o più di una valuta, provi il modulo in ciascuno. Cambi negozio, cambi lingua, cambi valuta e usi la funzione.

Superata: il modulo rispetta la Sua configurazione — corretto per ogni negozio, tradotto per ogni lingua, importi corretti per ogni valuta. Modalità di fallimento: un modulo costruito e testato su "negozio 1, inglese, euro" che codifica in modo rigido quelle assunzioni. Sembra a posto nella demo e va in pezzi sulla Sua seconda vetrina o sui prezzi dei Suoi clienti polacchi.

10. Compatibilità con PrestaShop e PHP

Come eseguirla: legga la dichiarazione di compatibilità sulla pagina del prodotto e la confronti con la Sua versione di PrestaShop (1.7, 8.x o 9.x) e la Sua versione di PHP.

Superata: il fornitore indica le versioni esatte supportate dal modulo e le mantiene aggiornate man mano che PrestaShop rilascia nuove versioni. Modalità di fallimento: "compatibile con tutte le versioni". Nessun modulo serio viene testato su ogni versione di PrestaShop e PHP mai rilasciata; quell'affermazione è marketing, ed è la riga con maggiori probabilità di rompersi il giorno in cui aggiornerà il Suo negozio.

11. Changelog e tracciato di supporto

Come eseguirla: cerchi un changelog datato e un canale di supporto reale prima di acquistare.

Superata: il modulo ha una cronologia visibile degli aggiornamenti e un modo per raggiungere una persona che lo mantiene. Modalità di fallimento: nessun changelog e nessun supporto significa nessun responsabile. Un modulo senza manutenzione è un modulo che prima o poi smetterà di funzionare a un aggiornamento di PrestaShop o PHP, senza nessuno che lo sistemi — e lo scoprirà nel momento peggiore possibile.

12. Il test di reversibilità

Come eseguirla: è l'intera checklist in un solo gesto, su staging. Faccia uno snapshot del Suo negozio. Installi il modulo. Lo disattivi. Lo disinstalli. Confronti il negozio con il Suo snapshot.

Superata: installazione → disattivazione → disinstallazione lascia il negozio sostanzialmente com'era — nessun file residuo, nessuna tabella orfana, nessuna pagina rotta. Modalità di fallimento: qualunque cosa non torni indietro. Se un modulo non può essere rimosso in modo pulito su una copia di prova, di certo non potrà essere rimosso in modo pulito dal Suo negozio in produzione sotto pressione.

Bandiere rosse e cosa significa davvero ciascuna

Non avrà sempre il tempo per tutte e dodici. Queste sono le scorciatoie — segnali che, da soli, giustificano uno sguardo molto più attento. Ciascuno corrisponde a un modo concreto in cui le cose vanno storte:

Nessuno di questi è la prova che un modulo sia difettoso. Codice economico e semplice può essere perfettamente valido; un piccolo fornitore può essere eccellente. Il problema non è mai il prezzo o l'autore — è il rischio non gestito. Una bandiera rossa significa solo che il rischio non è stato gestito per Lei, quindi deve gestirlo Lei stesso prima che raggiunga il Suo negozio in produzione.

Dove si collocano gli standard ufficiali

PrestaShop stesso pubblica le regole tecniche che un modulo ben fatto dovrebbe seguire. Non è necessario che Lei le implementi, ma sono utili per indirizzare un fornitore e coincidono con gran parte di quanto sopra. PrestaShop pubblica gli Standard Tecnici di Sviluppo che ci si aspetta un modulo ben fatto segua — disciplina degli override, igiene delle tabelle del core e delle prestazioni delle risorse, sicurezza e compatibilità di versione — insieme agli Standard di Qualità dietro il badge Verified+ sul marketplace Addons. Nessuno dei due è una garanzia di per sé — molti buoni moduli vivono al di fuori del marketplace e un badge non sostituisce le osservazioni qui sopra — ma sono un tassello sensato del quadro complessivo. Se acquista tramite il marketplace, la nostra guida all'acquisto su PrestaShop Addons spiega come leggere una scheda.

Un ordine di installazione sicuro, dall'inizio alla fine

Messo tutto insieme, il tutto è una sola sequenza tranquilla:

• Faccia un backup del Suo negozio in produzione — file e database.
• Installi su una copia di staging che rispecchi il Suo tema, i Suoi moduli e le Sue impostazioni reali.
• Faccia uno snapshot del negozio di staging, poi esegua le dodici verifiche qui sopra.
• Osservi la scheda Network sulla Sua homepage per nuovi domini e risorse estese a tutto il sito.
• Effettui un ordine di prova e metta alla prova ricerca, pagine prodotto e amministrazione.
• Disinstalli e confronti con il Suo snapshot — verifichi che torni tutto pulito.
• Solo allora installi in produzione, durante una finestra tranquilla, e controlli ancora una volta le Sue pagine principali.

Domande frequenti

Ho bisogno di uno sviluppatore per valutare un modulo?

Per la maggior parte di queste verifiche, no. Contare le richieste di terze parti, testare il checkout ed eseguire il test installazione → disattivazione → disinstallazione sono tutte cose che può fare da un browser e dal Suo back office su una copia di staging. Un paio di verifiche — guardare in /override, elencare le tabelle del database — richiedono accesso ai file o al database, che il Suo host o il Suo sviluppatore possono fornirle, ma non deve mai leggere alcun codice.

Se un modulo è sul marketplace ufficiale di PrestaShop, è automaticamente sicuro?

La validazione del marketplace e il badge Verified+ sono un segnale reale e utile — controllano molte di queste cose per Lei. Ma non sostituiscono l'osservazione del modulo mentre si comporta sul Suo negozio, con il Suo tema e i Suoi altri moduli. Molti buoni moduli vivono anche al di fuori del marketplace. Esegua le verifiche in ogni caso.

Il modulo è gratuito — è di per sé una bandiera rossa?

No. I moduli gratuiti ed economici possono essere eccellenti, e quelli costosi possono essere trascurati. Il prezzo non Le dice nulla su come si comporta il codice. La scheda di valutazione riguarda il rischio gestito, non il costo: un modulo gratuito che supera queste verifiche è più sicuro di uno a pagamento che le fallisce.

Se ho tempo per una sola verifica, quale?

Apra la scheda Network della Sua homepage e conti i nuovi domini di terze parti dopo l'installazione. Richiede un minuto, non serve alcun codice e intercetta il tipo di modulo trascurato più comune e più dannoso — quello che tassa ogni pagina per una funzione che vedrà raramente.

Scritto per esteso sembra molto; in pratica è un pomeriggio, ed è molto più conveniente del pomeriggio che altrimenti passerebbe a scoprire perché la Sua vetrina è diventata lenta, o perché una pagina non torna dopo che ha rimosso il modulo che l'ha rotta. Per la storia dietro il perché tutto questo conta — e un resoconto onesto di un errore che abbiamo commesso noi stessi — legga cosa può fare un modulo PrestaShop che la disinstallazione non annulla. E sì: esegua questa checklist anche sui nostri moduli. È a questo che serve. Se desidera che venga eseguita per Lei, la nostra scansione di sicurezza gratuita e l'audit delle prestazioni si basano esattamente su queste verifiche — e se preferisce che il Suo negozio tenga d'occhio queste cose in modo continuativo anziché solo al momento dell'installazione, è il compito di Performance Revolution e Security Revolution.