Come scegliere, installare e testare i moduli PrestaShop

Cosa faremmo

Definiremmo il risultato aziendale mancante, controlleremmo le impostazioni native e i moduli che possiedi già, valutando un nuovo modulo solo se resta una lacuna. Il percorso giusto dipende dal negozio esistente: configurazione, versioni dei moduli, integrazioni, personalizzazioni del tema, dati di catalogo e clienti, mercati e team che ne curerà la manutenzione. Sostituire uno strumento funzionante richiede un beneficio dimostrabile su quel negozio.

Applica la modifica scelta su una copia di staging protetta che riproduca la produzione, simulane configurazione e ripristino, poi pianifica il passaggio online. Concorda chi può fermare il rilascio, quali prove consentono la riapertura e come riconcilierai ordini o messaggi delle integrazioni se fosse necessario un recupero. Non copiare un vecchio database di staging su un negozio attivo per pubblicare un'impostazione di un modulo.

Se ti servono confronto dei candidati e rilascio, il PrestaShop Module Selection & Fit Assessment verifica i percorsi su una copia controllata del negozio; per un modulo già scelto, il PrestaShop Module Installation & Configuration Service lo installa, configura le impostazioni concordate e verifica il percorso interessato.

Scrivi un requisito verificabile

Fornisci lo stesso brief a ogni candidato. Descrivi l'attività che oggi non riesce, chi la esegue e il risultato che renderebbe utile la modifica. Distingui il comportamento essenziale dalla presentazione facoltativa, così un lungo elenco di funzioni non potrà nascondere un requisito mancante.

• Contesto del negozio: versioni esatte di core, PHP web e tema, moduli e personalizzazioni pertinenti, lingue, valute, negozi e gruppi clienti.
• Confini dei dati e delle integrazioni: campi del catalogo, record clienti o stati degli ordini coinvolti, destinazione successiva di quei record e sistema responsabile di ogni valore.
• Prove di accettazione: un prodotto o carrello rappresentativo, passaggi per riprodurre il caso, risultati attesi per cliente e personale e confronto con il negozio attuale.
• Vincoli operativi: chi configura la funzione, quali accessi gli servono, come viene monitorato il lavoro in background e chi la mantiene dopo la consegna.
• Condizioni di uscita: impostazioni e record da esportare o conservare, comportamento previsto di disattivazione e disinstallazione e percorso di recupero se la modifica fallisce.

Per esempio, “migliorare la consegna” è troppo generico per essere testato. “Offrire solo i corrieri idonei e ricalcolare il totale della consegna IVA inclusa quando un cliente abituale cambia indirizzo, poi esportare il servizio scelto al nostro sistema ordini” fornisce al fornitore un percorso concreto da dimostrare. Uno screenshot del selettore corrieri risponde solo a una parte del brief.

Controlla la compatibilità esatta con PrestaShop e PHP

Registra la versione completa di PrestaShop, la versione PHP del web, la versione del tema e i moduli installati in Parametri avanzati > Informazioni e Gestione moduli. Una dichiarazione come “supporta la 1.7” è meno utile di una versione specifica e una combinazione PHP testata.

La dichiarazione di compatibilità con il core è $this->ps_versions_compliancy nella classe PHP principale del modulo. Per esempio, questa dichiarazione usa la versione del negozio in esecuzione come limite superiore:

$this->ps_versions_compliancy = [
    'min' => '1.6.1.0',
    'max' => _PS_VERSION_,
];

Un intervallo dichiarato è un vincolo di installazione, non un report di test. Il PHP del modulo viene eseguito con i permessi del negozio e può accedere a database, dati clienti e file scrivibili, quindi i soli controlli nel browser non dimostrano la sicurezza del codice. Leggi separatamente i vincoli PHP e delle librerie di Composer. L'ambiente PHP deve soddisfare insieme core, modulo e dipendenze. Una sintassi nuova può causare un errore prima che il modulo mostri un messaggio utile. Non abbassare un requisito nel codice per aggirare il controllo.

Fissa ogni ambiente di test a una versione esatta del core e di PHP. Per i test storici, PrestaShop 1.7.6 supporta PHP solo fino alla 7.2; la 1.7.8 fino alla 7.4; e PrestaShop dalla 8.0 alla 8.2 fino alla 8.1. Queste vecchie combinazioni sono riferimenti di compatibilità, non raccomandazioni attuali di hosting.

I requisiti di PrestaShop 9 distinguono la 9.0, che supporta PHP da 8.1 a 8.4, dalla 9.1, che supporta PHP da 8.1 a 8.5. Verifica i requisiti della versione esatta di destinazione, inclusa la 9.2, prima di scegliere l'ambiente di esecuzione. Esegui i test pertinenti sulla 9.2 oltre che su ogni versione precedente supportata.

Esamina override/, script di installazione e aggiornamento, definizioni dei servizi e ogni file copiato fuori dal modulo. Una directory override vuota dice solo che gli override convenzionali sono assenti. Cerca anche le registrazioni degli hook, poi confrontale con quelle effettivamente installate per ogni negozio.

Prepara lo staging e un backup ripristinabile

La copia di staging dovrebbe corrispondere alla produzione per core, PHP ed estensioni, motore di database, tema, moduli, impostazioni del negozio e configurazione del server. Confronta contesto multinegozio, lingue, valute, cache e connettività in uscita. Una demo pulita è utile per vedere una funzione; non riproduce le interazioni del tuo negozio.

Proteggi la copia dall'accesso pubblico e dall'indicizzazione nei motori di ricerca. Rimuovi o anonimizza i dati dei clienti dove praticabile. Disattiva acquisizione di pagamenti reali, email ai clienti, webhook di produzione e integrazioni programmate. Usa credenziali sandbox per i pagamenti e una casella email controllata.

1. Esegui insieme il backup completo dei file del negozio e del database, inclusi override, personalizzazioni del tema e configurazione.
2. Conserva lo ZIP esatto del modulo attuale, la versione e l'esportazione della configurazione se disponibile.
3. Archivia i backup fuori dalla radice web pubblica e conferma di poterli ripristinare.
4. Registra una situazione iniziale per le pagine e i flussi che proverai.

Per un database InnoDB, uno sviluppatore può usare un dump logico coerente come il seguente da una directory di backup privata. Sostituisci database e account con i tuoi valori reali; coordina separatamente le scritture e le eventuali tabelle non transazionali.

mysqldump --single-transaction -u backupuser -p prestashop > before-module.sql

Consulta la guida allo staging e la guida ai backup per la preparazione più ampia.

Installa lo ZIP e diagnostica gli errori di caricamento

In PrestaShop 8 e 9, apri Moduli > Gestione moduli > Carica un modulo e carica lo ZIP installabile così come fornito. Mantieni intatto il nome tecnico della cartella. Per esempio, mprcanonicalmanager/mprcanonicalmanager.php appartiene a modules/mprcanonicalmanager/, con dipendenze e altre directory accanto al file principale.

Un download del repository può avere una directory contenitore aggiuntiva o essere privo delle dipendenze già predisposte per l'uso. Usa il pacchetto di rilascio destinato all'installazione. La sola copia dei file non esegue install(), che può creare tabelle, registrare hook, aggiungere schermate amministrative e inizializzare valori predefiniti.

Se il caricamento dal browser fallisce, confronta le dimensioni dell'archivio con i valori effettivi web di upload_max_filesize e post_max_size. Quest'ultimo deve contenere anche il resto della richiesta POST. Informazioni mostra alcuni valori PHP; ricava post_max_size dalle impostazioni PHP dell'hosting o da una diagnostica privata dell'ambiente web. php -i dalla CLI può leggere una configurazione diversa.

; Example limits for a ZIP smaller than 64 MB
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300

Questi sono esempi, non requisiti minimi per ogni modulo. Controlla anche limiti del corpo delle richieste di proxy e server web, spazio temporaneo, spazio di estrazione, estensioni richieste e permessi di scrittura. Usa direttive php_value in .htaccess solo dove l'integrazione PHP di Apache le supporta; non sono una soluzione generale per PHP-FPM.

Se necessario, estrai lo ZIP localmente e carica via SFTP la sua unica directory tecnica del modulo. Poi usa Gestione moduli per installarlo. Conferma proprietà e accesso dell'utente PHP effettivo, anziché concedere permessi di scrittura a chiunque.

Controlla var/logs/, i log PHP-FPM e del server web durante l'installazione. Parametri avanzati > Log è un'altra fonte possibile, ma gli errori iniziali potrebbero non raggiungere mai quel logger. Un modulo visibile su disco può comunque aver fallito durante creazione delle tabelle, registrazione degli hook, caricamento delle dipendenze o un altro passaggio dell'installazione. Conserva l'errore e controlla lo stato parziale prima di riprovare. Non eliminare alla cieca tabelle del modulo o ruoli di autorizzazione.

Dopo il successo, apri Configura, inserisci le impostazioni richieste per il negozio, salva e ricarica. Controlla permessi, traduzioni, voci del menu e contesto del negozio previsto.

Esegui test funzionali e di regressione

Trasforma l'elenco documentato delle funzioni e il brief dei requisiti in una checklist con risultati attesi. Prova persistenza della configurazione, permessi e tutti i tipi di pagina interessati. Usa gli stessi dati di prova prima e dopo l'installazione. Conserva insieme ZIP del modulo, configurazione, passaggi di test, risultato atteso ed effettivo e prove anonimizzate, così il fornitore potrà riprodurre un errore.

1. Aggiungi un prodotto al carrello dalla sua pagina prodotto, da una categoria e dai risultati di ricerca. Questi punti di ingresso possono avere markup e JavaScript diversi anche quando la loro modifica del carrello raggiunge lo stesso CartController.
2. Completa il checkout in modalità sandbox. Conferma prodotti, combinazioni, indirizzi, scelte di consegna, imposte, sconti, valuta e totali sia nell'ordine sia nel sistema di pagamento.
3. Registra un cliente, controlla l'email prevista, esci e accedi di nuovo. Controlla lo storico dell'account.
4. Prova le ricerche supportate dal tuo negozio, inclusi nomi prodotto, riferimenti ed EAN dove indicizzati.
5. Apri i dettagli dell'ordine in amministrazione. Controlla informazioni sul corriere, schede, note e permessi pertinenti del personale.
6. Svuota il carrello e ripeti le interazioni principali su dispositivi mobili, includendo un viewport ristretto, per esempio di 375 pixel.
7. Passa a ogni lingua, valuta e negozio pertinenti. Conferma che impostazioni e contenuti restino nel loro ambito previsto.

Negli strumenti di sviluppo del browser, esamina errori della console, richieste AJAX fallite, 404 degli asset e host esterni inattesi. Visita pagine in cui la funzione appare e pagine in cui non dovrebbe svolgere alcun lavoro. Controlla le copie dei template dei moduli nel tema in themes/your-theme/modules/ quando una funzione aggiornata non appare.

Controlla separatamente attività programmate e webhook. Conferma autenticazione, frequenza, destinazione e gestione degli errori. Un caricamento di pagina riuscito non dimostra che il lavoro in background riesca.

Analizza un modulo che supera la demo ma fallisce sul tuo negozio

Supponiamo che tu stia provando un blocco di prodotti consigliati su un negozio multilingue con combinazioni ed esportazione ordini. La demo dimostra che i consigli compaiono. Il tuo test di accettazione deve anche dimostrare che i clienti acquistano ancora l'articolo previsto e il personale riceve l'ordine corretto.

Se l'aggiunta al carrello dalla categoria funzionava prima dell'installazione e ora fallisce, conserva il confronto e ferma il rilascio. Isola l'interazione tramite i controlli dei conflitti descritti sotto, poi ripeti lo stesso scenario dopo la correzione. Superare il test di visualizzazione dei consigli non compensa un percorso d'acquisto guasto.

Misura asset, query e dipendenze esterne

Confronta caricamenti ripetuti delle pagine nelle stesse condizioni. Separa i risultati con cache fredda e calda. Registra tempo di risposta del server, numero di richieste, dimensioni trasferite e query lente. Imposta un budget di accettazione per il tuo negozio senza trattare una soglia fissa in millisecondi come universale.

I moduli hanno impatti diversi. Uno strumento amministrativo può non aggiungere asset al negozio; una funzione condizionale può essere eseguita solo su richieste selezionate. Conta hook, query e asset effettivamente eseguiti. Profila chiamate ripetute al database nei cicli dei prodotti e richieste esterne sincrone durante il rendering delle pagine.

Modalità debug e profilazione sono separate. Il profiler storico di query e tempi usa _PS_DEBUG_PROFILING_ in config/defines.inc.php. Il profiler Symfony si applica alle richieste Symfony idonee quando configurato. Nessuno dei due garantisce una suddivisione dei tempi per ogni richiesta del negozio o non riuscita. Usa brevemente la profilazione su staging protetto.

Preferisci registerStylesheet() e la corrispondente API degli script per la gestione degli asset e l'integrazione CCC. Controlla anche versionamento esplicito e invalidazione alla distribuzione. La registrazione non garantisce automaticamente l'aggiornamento della cache, e un link diretto non diventa un 404 solo perché svuoti la cache.

Puoi elencare gli host delle risorse osservati dalla pagina attuale con questo esempio nella console del browser:

const hosts = {};
for (const entry of performance.getEntriesByType('resource')) {
    const host = new URL(entry.name, location.href).host;
    if (host && host !== location.host) {
        hosts[host] = (hosts[host] || 0) + 1;
    }
}
console.table(hosts);

Esamina i tuoi sottodomini CDN oltre ai servizi di terze parti. Questo elenco copre le risorse osservate nel browser, non il traffico tra server o ogni forma di trasferimento dati. Chiedi perché serve un nuovo host, quali dati riceve e come si comporta la funzione quando è indisponibile. Ripeti l'osservazione negli stati pertinenti di consenso e accesso, poiché una richiesta può comparire solo dopo un'interazione o una modifica delle autorizzazioni.

In staging, usa il blocco delle richieste del browser per simulare l'indisponibilità di un host esterno specifico della funzione, poi prova di nuovo la pagina. Registra se la funzione facoltativa segnala chiaramente il problema e se navigazione e acquisto funzionano ancora. Questo verifica solo la dipendenza del browser; fai simulare separatamente allo sviluppatore timeout lato server e chiamate in background fallite.

Prova gli aggiornamenti e prepara un ripristino completo

Leggi il changelog e i requisiti prima di sostituire i file. Esegui backup di file e database, registra la versione installata e conserva entrambi gli ZIP. Prova un aggiornamento dalla versione effettivamente in produzione, non solo una nuova installazione del nuovo rilascio.

Usa il flusso supportato di aggiornamento di Gestione moduli o di caricamento ZIP. Controlla che la versione installata nel database avanzi e che le migrazioni upgrade/install-X.Y.Z.php applicabili si completino. La sola copia di nuovi file via SFTP non dimostra che le migrazioni siano state eseguite.

La configurazione risiede spesso nel database, ma il codice di aggiornamento può modificarla o rimuoverla. Confronta impostazioni salvate, tabelle personalizzate, hook, permessi e copie dei template nel tema dopo l'aggiornamento. Tratta Reset separatamente: può disinstallare e reinstallare un modulo, con gestione dei dati dipendente dall'implementazione e dalle opzioni di conservazione. Non è un sostituto sicuro di una migrazione.

Simula nuova installazione, aggiornamento, disattivazione, riattivazione e disinstallazione come operazioni distinte su copie eliminabili. Confronta ogni risultato con la politica di conservazione documentata. Una disinstallazione pulita può conservare intenzionalmente recensioni o record di integrazione; eliminare tutto non è automaticamente corretto. Esporta i dati necessari prima di provare pulizie distruttive.

Preferisci Parametri avanzati > Prestazioni > Svuota cache. Anche uno svuotamento coordinato tramite CLI può essere appropriato:

php bin/console cache:clear --env=prod

Eseguilo dalla radice del negozio con il binario PHP e l'utente del filesystem corretti. Se serve un recupero del filesystem, interrompi traffico in ingresso e worker, conferma percorsi e proprietà della cache, ricostruiscila e verifica il negozio prima di riaprire. La cache PrestaShop è rigenerabile; richieste concorrenti, dipendenze mancanti e permessi possono far fallire la ricostruzione. Coordina separatamente OPcache del web ed eventuali cache dell'intera pagina, proxy o CDN.

Quando devi tornare a una versione precedente

1. Metti il negozio attivo interessato in manutenzione e ferma le attività che possono scrivere dati correlati.
2. Salva stato guasto, log e dettagli delle transazioni recenti per la diagnosi.
3. Ripristina una directory pulita del modulo precedente senza mescolare versioni. Conserva la copia sostituita fuori dalla directory pubblica dei moduli.
4. Ripristina lo stato corrispondente del database o applica una migrazione inversa fornita da uno sviluppatore. I soli file non possono annullare modifiche allo schema o ai dati.
5. Riconcilia ordini, pagamenti e variazioni delle scorte successivi al backup. Non sovrascrivere nuove transazioni reali con una vecchia istantanea dell'intero negozio.
6. Svuota le cache pertinenti e ripeti i test di funzioni, configurazione e checkout.

Non usare Disinstalla o Elimina come passaggio per tornare a una versione precedente se non comprendi quali dati e file rimuovono. Un modulo può rimuovere intenzionalmente le proprie tabelle e impostazioni. Ottieni lo ZIP precedente esatto da un archivio dei rilasci o dall'assistenza senza presumere che ogni account fornisca versioni più vecchie.

Isola gli errori e risolvi le personalizzazioni sovrapposte

In staging, riproduci l'errore con entrambi i moduli sospetti, con ciascuno da solo e senza nessuno dei due. Registra lo stato dopo ogni modifica. Per un insieme più ampio, disattiva un gruppo controllato, poi restringi la ricerca. Prova dipendenze e combinazioni: l'ultimo modulo attivato può esporre un'interazione senza esserne l'unica causa.

Più moduli possono condividere un hook. La posizione può contare per l'output visivo, ma l'ordinamento non è una soluzione universale. Confronta modifiche del carrello, dati restituiti, listener di eventi, selettori CSS, librerie incluse, template e configurazione. Hook e servizi Symfony riducono l'accoppiamento diretto al core; non garantiscono un funzionamento senza conflitti.

Il core può unire override che aggiungono metodi diversi a una classe. Metodi, proprietà o costanti sovrapposti possono causare un conflitto esplicito. Non unire preventivamente due metodi presumendo che il prossimo installer li accetti. Organizza una patch di compatibilità con un solo responsabile dell'implementazione combinata e una procedura documentata di installazione, aggiornamento e rimozione.

Esamina file di override, commenti che ne indicano la provenienza, impostazioni degli override attivi e voci dei percorsi nell'indice delle classi. Un elenco di nomi di classi da solo non identifica i responsabili né dimostra che un file sia orfano. Un file su disco non viene eseguito automaticamente su ogni pagina; un override viene usato quando viene caricata la classe a cui è associato.

Se il back office è inaccessibile, usa la normale azione di disattivazione o il comando console supportato dove possibile. Rinominare la directory di un modulo è un isolamento di emergenza dei file e richiede un percorso di ritorno registrato. Non disinstalla gli override né annulla servizi compilati e modifiche al database. Conserva i log prima di svuotare le cache. Per una risposta vuota, esamina stato HTTP e log del server; usa l'output di debug solo su una copia protetta e disattivalo dopo, perché può rivelare configurazioni sensibili.

Consulta la risoluzione dei problemi PrestaShop per il recupero in base al sintomo.

Automatizza i controlli sul pacchetto di rilascio

Per lo sviluppo di moduli, usa PHPUnit per la logica applicativa testabile indipendentemente, come calcolatori e formattatori. Aggiungi test di integrazione per installazione, migrazioni, hook e archiviazione con ambito di negozio. Usa test nel browser per flussi cliente significativi come accesso, aggiunta al carrello e checkout.

Crea una matrice delle combinazioni esatte supportate di core, PHP, database e tema. Includi le versioni attuali di destinazione e la versione più vecchia che dichiari effettivamente di supportare. Archivia i risultati dei test con lo ZIP esatto del rilascio o il commit, non solo con un intervallo di compatibilità del sorgente.

Una pipeline CI può costruire l'archivio, controllare dipendenze e sintassi, installarlo su negozi puliti, aggiornare da versioni precedenti supportate del modulo ed eseguire test essenziali nel browser. Le scansioni statiche delle API deprecate integrano i test di esecuzione; non li sostituiscono. Prova disinstallazione e conservazione documentata dei dati su copie eliminabili.

Valuta schede, venditori e condizioni d'acquisto

Usa il brief dei requisiti quando confronti le schede prodotto. Confronta la stessa funzione sul tuo catalogo tramite demo o prova, se disponibili. Installa i candidati separatamente prima di provare le combinazioni previste. La demo del venditore mostra il comportamento atteso; chiedi quale valutazione controllata sia disponibile per il tuo negozio effettivo e se la licenza consente un'installazione privata di staging.

• Compatibilità: ottieni requisiti precisi di core, PHP e tema, comprese le limitazioni note.
• Manutenzione: leggi rilasci datati, risposte ai problemi e correzioni di sicurezza. Una data di rilascio vecchia richiede contesto; da sola non dimostra abbandono.
• Documentazione: cerca requisiti, configurazione, conservazione dei dati, attività in background e passaggi di recupero.
• Recensioni: preferisci descrizioni di una configurazione reale e dell'esito dell'assistenza rispetto alla media delle stelle.
• Accesso al codice: controlla se il tuo sviluppatore può esaminarlo e mantenerlo. Modifiche al core non documentate o dipendenze opache meritano un'indagine.
• Sicurezza: cerca nome tecnico e versione esatti su Friends of Presta e negli avvisi del manutentore. L'assenza di avvisi pubblicati non dimostra la sicurezza. Confronta versioni interessate, gravità e correzioni disponibili; il semplice numero di avvisi può riflettere quanto un modulo è stato esaminato.

La revisione dei moduli nel Marketplace e i programmi di qualità sono segnali utili, ma il tuo negozio richiede comunque test in staging. Un venditore diretto, un venditore del marketplace, un progetto open source mantenuto o uno sviluppatore su misura possono essere tutti adatti. Confronta ambito della licenza, prezzo comprensivo di imposte, rinnovo, aggiornamenti, assistenza, lavoro personalizzato e condizioni di controversia per l'offerta effettiva. Valuta implementazione e manutenzione del modulo effettivo.

Le FAQ su assistenza e aggiornamenti del Marketplace descrivono Business Care e le condizioni di rimborso per gli acquisti di addon sul Marketplace. Per gli acquisti coperti dalle FAQ, Business Care include il primo anno con l'acquisto e si rinnova automaticamente. Le richieste di rimborso vanno presentate per iscritto; l'idoneità degli addon include problemi specificati entro un mese, con previo contatto del venditore rilevante nei casi di malfunzionamento. Ricontrolla le condizioni per il tuo acquisto, prodotto e paese prima di pagare, registra condizioni e data e conserva la conversazione con l'assistenza. Non dare per scontati rimborso o tempi di risposta.

Le offerte gratuite possono essere progetti della comunità, edizioni lite, integrazioni legate a un servizio o prodotti dismessi. Leggi i loro limiti effettivi e gli obblighi di assistenza. La richiesta di un account di terzi può essere legittima. Esamina finalità dei dati, destinatari, conservazione e condizioni contrattuali senza trattare la registrazione dell'account come prova di raccolta indiscriminata dei dati.

Stima il costo totale usando i tuoi costi effettivi di licenza, implementazione, hosting, manutenzione, assistenza e migrazione. Gratuito non significa intrinsecamente insicuro e a pagamento non garantisce assistenza a lungo termine. Includi formazione del personale, eventuali servizi esterni ricorrenti, esportazione dati e lavoro di rimozione. Confronta i candidati sullo stesso periodo usando le condizioni effettive del fornitore e le tariffe del tuo team.

Uno strumento gratuito può svolgere un compito definito: Security Scan segnala problemi di sicurezza locali con posizione e gravità e fornisce istruzioni di correzione manuale. Non corregge il negozio né certifica la sicurezza di un modulo candidato. Usa un rilievo per orientare l'indagine, poi verifica il comportamento pertinente in staging.

Cosa chiedere allo sviluppatore o all'agenzia

• Quale versione hai testato su questa esatta combinazione di core, PHP e tema e quali moduli o integrazioni installati richiedono lavoro di compatibilità separato?
• Puoi dimostrare il percorso di accettazione con i nostri dati rappresentativi, inclusi errore e recupero, oltre alla schermata delle impostazioni?
• La licenza copre i nostri negozi e il dominio privato di staging? Chi riceve download, aggiornamenti e assistenza se cambiamo agenzia?
• Quali impostazioni, tabelle, override, attività pianificate e servizi esterni cambiano? Cosa resta dopo disattivazione o disinstallazione?
• Chi corregge un'interazione tra fornitori, quali interventi di assistenza sono inclusi e chi mantiene una patch di compatibilità personalizzata?
• Quali prove riceveremo alla consegna e chi è responsabile del ripristino e della riconciliazione dei nuovi ordini se il lancio fallisce?

Verifica i moduli già installati

Elenca moduli attivi e inattivi, responsabili, versioni, scopo aziendale, dipendenze e preparazione agli aggiornamenti. Indica per ciascuno se mantenerlo, configurarlo, aggiornarlo, sostituirlo o ritirarlo, con una persona responsabile della decisione. Rimuovi le funzioni ridondanti solo dopo aver controllato cosa ne dipende. Prima disattiva per un test reversibile, poi disinstalla tramite l'azione supportata e rimuovi i file inutilizzati secondo il piano di conservazione.

Non dedurre l'inutilizzo da un blocco vuoto nella vetrina. Un modulo apparentemente inattivo può esportare ordini, fornire un'azione amministrativa o eseguire un feed occasionale. Chiedi al responsabile di quel flusso e osserva l'esecuzione pianificata pertinente prima di ritirarlo. Rimuovere una dipendenza perché non ha un widget visibile può interrompere un'integrazione funzionante.

La normale disattivazione impedisce il percorso standard ModuleFrontController per un modulo inattivo. Non rimuove endpoint PHP autonomi, override installati o tutto il codice di integrazione. I file residui meritano una verifica di sicurezza anche quando non aggiungono costi di esecuzione misurati.

Questi esempi in sola lettura usano ps_. Sostituiscilo con il prefisso effettivo. Nel multinegozio, esamina anche le associazioni ai negozi; il flag globale di attivazione non è un inventario completo negozio per negozio.

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

SELECT hm.id_module, hm.id_hook, h.name AS hook_name
FROM ps_hook_module hm
LEFT JOIN ps_module m ON m.id_module = hm.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.id_module IS NULL;

SELECT m.name, COUNT(*) AS registrations
FROM ps_hook_module hm
JOIN ps_module m ON m.id_module = hm.id_module
GROUP BY m.name
ORDER BY registrations DESC;

Le registrazioni degli hook possono includere righe separate per negozio, e un conteggio elevato non dimostra un'esecuzione costosa. Indaga sulle registrazioni orfane invece di eliminare righe a mano. Confronta la struttura del database prima e dopo installazione e disinstallazione, compresi i dati conservati documentati. I controlli dei file in override/classes/ e override/controllers/ integrano l'inventario del database.

Quando rivedi codice SQL, preferisci il binding dei parametri dove disponibile. Nel codice storico, controlla escape dei valori corretto per il contesto, conversioni a intero e gestione degli identificatori. Traccia come l'input non affidabile raggiunge ogni query e come viene protetto quel contesto.

Scegli le funzioni in base alle lacune effettive del tuo negozio

Controlla prima le capacità native. Non esiste un insieme universale di moduli essenziali o una soglia di numero di prodotti che renda obbligatoria un'estensione.

La documentazione del checkout nativo in una pagina spiega le modifiche di compatibilità della versione 9.2. Usa le pagine di assistenza dei moduli collegate per i dettagli di configurazione.

Prendi le decisioni di lancio prima che influiscano sui dati reali

Definisci una politica stabile degli URL prima di pubblicare link. Il core genera URL dalle rotte attuali e dai dati delle entità; i prodotti non memorizzano un URL completo immutabile alla creazione. Gli ID numerici non creano di per sé contenuti duplicati. Rivedi categorie predefinite, reindirizzamento canonico e link generati dal tema prima di modificare le rotte. Mappa i vecchi URL pubblicati quando una modifica richiede reindirizzamenti.

Definisci presto la politica di metadati e dati strutturati, poi verifica l'output reale. Le entità esistenti possono ricevere modelli di metadati in massa in SEO Revolution; distingui le modifiche ai metadati memorizzati dall'output dinamico. Non devi compilare tutto manualmente a posteriori.

Concorda la politica di fatturazione con il commercialista prima di emettere fatture. La creazione dipende dalle impostazioni delle fatture e dal flag di fatturazione dello stato dell'ordine. Il core supporta prefissi, numero iniziale e azzeramento annuale. Applica le regole di correzione e verifica della tua giurisdizione quando modifichi documenti emessi o numerazione.

Decidi quali dati clienti ti servono davvero alla registrazione. La modalità B2B nativa offre campi azienda e identificativi; i dati personalizzati richiedono un'estensione campi adatta e una finalità di raccolta lecita. Customer Extra Info (IP Ban) non è un generatore di campi di registrazione. Pianifica come i clienti esistenti potranno fornire i nuovi dati obbligatori.

Configura l'accesso ad analisi e Search Console prima delle campagne dove praticabile. Il tracciamento non può ricreare eventi di interazione non raccolti. Rispetta i requisiti del consenso e verifica la situazione iniziale prima di usarla per decidere. Prova il checkout prima del lancio; una sostituzione a pagamento richiede un vantaggio dimostrato di funzionalità o compatibilità per il tuo negozio.

Aggiungi chat, fedeltà, widget social e altre funzioni di presentazione quando puoi definirne lo scopo e misurarne l'effetto. Installa una modifica alla volta. Dopo la pubblicazione online, ripeti i controlli critici e monitora i log. Se ti serve aiuto con un modulo MPR, invia versione, ambiente, passaggi di riproduzione, risultati attesi ed effettivi e log anonimizzati tramite l'assistenza.

Decidi se la modifica testata può andare online

Usa i risultati dei test per decidere il rilascio, senza farne una media. Un problema irrisolto al checkout, un accesso scorretto ai dati clienti, un trasferimento dati inspiegato o un recupero non dimostrato bloccano il lancio anche se gli altri controlli riescono. Registra esplicitamente i limiti minori, con un responsabile e un'azione concordata.

1. Congela il pacchetto testato e registrane versione, dipendenze, impostazioni e configurazione esatta del negozio usata. Riesamina le modifiche alla produzione intervenute da quando è stata creata la copia.
2. Ottieni l'accettazione dei risultati per clienti e personale da parte del responsabile aziendale. Assicurati che chi elabora gli ordini sappia cosa cambia e dove compaiono gli errori.
3. Scegli la finestra di rilascio, esegui il backup corrispondente di file e database e conferma i passaggi di ripristino simulati. Sospendi attività e traffico interessati se la migrazione lo richiede.
4. Applica alla produzione l'installazione o l'aggiornamento supportati e la configurazione registrata. Controlla contesto del negozio, credenziali ed endpoint previsti; i valori sandbox dello staging non devono diventare impostazioni reali senza che nessuno se ne accorga.
5. Esegui i controlli critici online adatti al modulo usando la procedura autorizzata del fornitore, se prevista. Controlla l'ordine, l'email o il record a valle risultante oltre alla pagina visibile.
6. Riattiva consapevolmente le attività interessate, monitora log e code delle integrazioni e indica chi risponde a un controllo fallito. Se annulli la modifica, conserva e riconcilia le transazioni create durante la finestra.

Consegna al team impostazioni finali, pacchetto conservato, prove dei test, limiti noti, contatto dell'assistenza e procedura di recupero. Riutilizza i controlli pertinenti dopo la prossima modifica di core, PHP, tema o integrazione; un vecchio report di accettazione descrive la configurazione che aveva superato i test allora.

Domande dei titolari

Quanti moduli sono troppi?

Usa l'inventario per individuare i moduli senza uno scopo aziendale o un manutentore e i test misurati per trovare interazioni costose. Il solo numero non rivela se un negozio molto attivo è sano o se uno quasi vuoto ha un problema grave.

Posso fare i controlli da solo?

Puoi confrontare comportamento visibile, impostazioni salvate e richieste del browser in staging. Chiedi a uno sviluppatore di esaminare modifiche allo schema, permessi, chiamate lato server e migrazioni che non puoi valutare. Una checklist del browser completata con successo è una prova utile, non un audit completo del codice o della sicurezza.

Un badge Marketplace, una licenza a pagamento o una scansione recente garantiscono la sicurezza?

No. Ognuno risponde a una parte della decisione d'acquisto. Richiedi prove per la tua configurazione effettiva, indaga sui rilievi critici e assicurati di avere un manutentore e un percorso di recupero prima del lancio.

Devo aggiornare un vecchio modulo o sostituirlo?

Chiedi se un aggiornamento supportato soddisfa il requisito e preserva dati e personalizzazioni. In caso contrario, confronta sostituzione o sviluppo circoscritto, inclusi costi di migrazione e rimozione. Conserva la versione ripristinabile mentre simuli il percorso scelto.

Una disinstallazione riuscita dimostra che il ripristino funzionerà?

Prova il recupero che useresti davvero dopo un aggiornamento fallito. La disinstallazione può eliminare record, mentre tornare a una versione precedente può richiedere file e modifiche al database corrispondenti. Esegui il test di disinstallazione su una copia eliminabile e usa la procedura documentata di recupero per i dati operativi.

Posso aggiungere queste funzioni a un negozio già attivo?

Sì. Definisci l'effetto su dati esistenti, URL pubblicati, documenti emessi e sistemi collegati, poi simula la modifica su una copia. Usa aggiornamenti in massa o migrazioni supportati dove necessario e programma il passaggio; aggiungere una funzione non richiede automaticamente di ricostruire il negozio.