Aggiornamento di PrestaShop: cosa verificare prima del preventivo?

Per una valutazione affidabile dell’aggiornamento di PrestaShop sono necessari la versione completa del negozio, l’ambiente server, il tema, i moduli chiave e la descrizione delle modifiche personalizzate. Il solo numero di versione non definisce l’entità del lavoro. Due negozi con la stessa versione possono richiedere una preparazione completamente diversa, se uno utilizza funzioni standard e l’altro ha un checkout modificato, un’integrazione di magazzino e regole di prezzo personalizzate.

Questa guida aiuta a preparare una richiesta di aggiornamento e a concordare i criteri di accettazione. Non è un’istruzione per avviare l’aggiornatore senza un backup preventivo e senza verificare le dipendenze.

La versione di PrestaShop e PHP devono costituire una combinazione supportata

Annota la denominazione completa della versione attuale e di quella pianificata del negozio. Verifica il PHP che gestisce il sito e il PHP utilizzato da CRON e dai comandi console. L’hosting può mettere a disposizione versioni diverse per queste modalità di esecuzione. La modifica dell’impostazione nel pannello del dominio non deve necessariamente cambiare l’interprete usato dai processi pianificati.

Nella documentazione verificata il 13 settembre 2026, PrestaShop 9.0 supporta PHP 8.1–8.4, mentre PrestaShop 9.1 — PHP 8.1–8.5. Anche le versioni PHP consigliate differiscono tra questi rami. Questo è un esempio del perché l’informazione “supporta PrestaShop 9” sia insufficiente nella scelta dell’ambiente. Fonte: requisiti ufficiali di PrestaShop 9.

L’ambiente supportato del solo motore del negozio non conferma ancora la compatibilità del tema o dei moduli. Prima di aggiornare PHP, verifica anche i loro requisiti, le estensioni del server, i limiti di memoria e il modo in cui vengono eseguite le integrazioni. Non iniziare cambiando PHP in produzione solo perché un numero più recente sembra più vantaggioso.

Inventario: inizia dalle funzioni critiche

L’elenco di tutti i moduli è utile, ma il fornitore dovrebbe soprattutto sapere quali funzioni sostengono le vendite quotidiane. Indica pagamenti, spedizioni, punti di ritiro, fatturazione, magazzino, importazioni di prezzi e giacenze, prenotazioni e regole B2B speciali. Aggiungi l’informazione su chi gestisce ogni integrazione.

Nella fase del primo contatto sono sufficienti informazioni tecniche e una descrizione del processo. Non inserire password, chiavi API o dati dei clienti in un documento accessibile pubblicamente. Se sarà necessario l’accesso a una copia, concorda la modalità di trasmissione e l’ambito dei permessi.

Cosa resta, cosa aggiorniamo e cosa sostituiamo?

Ogni elemento importante dovrebbe ricevere una decisione e la relativa motivazione. “Resta” significa utilità confermata nella configurazione pianificata. “Da verificare” è uno stato corretto prima dell’analisi; una sicurezza simulata rende più difficile la valutazione e l’accettazione successiva.

Non valutare un modulo esclusivamente in base al fatto che si possa installare. L’installazione non conferma il calcolo dello sconto, il salvataggio del punto di ritiro né il completamento della comunicazione con il magazzino. Allo stesso modo, una homepage corretta non è la prova di un aggiornamento corretto del negozio.

Modifiche personalizzate: il rischio maggiore può essere invisibile nel pannello

Chiedi alle persone che gestiscono il negozio quali modifiche sono state introdotte nel corso degli anni: campi aggiuntivi, stati ordine insoliti, modifiche di prezzo, esclusioni dei corrieri o esportazioni speciali. Una parte di esse può esistere al di fuori dei moduli visibili nel pannello.

È utile una breve descrizione del comportamento: “per questo gruppo di clienti il prezzo viene calcolato così”, “questi prodotti escludono questo corriere”, “dopo questo stato inviamo il documento al sistema”. Da una descrizione del genere è possibile preparare una prova di accettazione. Il solo nome del file override non spiega il suo significato di business.

La ricostruzione di una funzione mancante può richiedere un lavoro separato. Dovrebbe essere identificata nell’ambito o esplicitamente indicata come dipendenza da chiarire, invece di emergere solo dopo il passaggio del negozio.

Copia di test e criteri di accettazione

L’aggiornamento viene eseguito prima su una copia con integrazioni controllate. La preparazione della copia comprende anche la protezione dell’accesso, l’interruzione degli invii di produzione e la separazione della configurazione dei servizi esterni. La copia deve consentire una prova del processo, non replicare inconsapevolmente il funzionamento del negozio di produzione.

La guida ufficiale all’aggiornamento dal pannello descrive l’uso dello strumento di aggiornamento. L’ambito dell’accettazione dovrebbe inoltre riflettere le funzioni del negozio; il punto di riferimento è la checklist dopo l’aggiornamento.

• Confronta prodotti selezionati, combinazioni, prezzi e giacenze.
• Verifica l’account cliente, il carrello, gli indirizzi e i metodi di spedizione e pagamento importanti.
• Controlla l’esito dell’ordine nel pannello e nei sistemi in cui dovrebbe arrivare.
• Esegui prove controllate di importazioni, esportazioni e attività CRON.
• Confronta gli URL importanti, i canonical, i reindirizzamenti, le versioni linguistiche e le sitemap.
• Registra errori, decisioni e condizioni di accettazione, non solo un generico “test completati”.

Una scheda di controllo più dettagliata del processo di acquisto è disponibile nella guida sulla modifica del checkout. Per i lavori sugli indirizzi, utilizza anche il testo esistente sul mantenimento dei vecchi link e dei reindirizzamenti.

Il piano di passaggio e di ritorno deve tenere conto dei nuovi ordini

Prima dei lavori, stabilisci il momento dell’esecuzione della copia finale dei file e del database, il modo di limitare le modifiche ai dati e l’ordine di arresto e ripresa delle integrazioni. Designa la persona che prende la decisione di avviare il negozio e le condizioni alle quali si torna alla versione precedente.

Il ripristino di una copia precedente all’aggiornamento può eliminare dal database corrente ordini o modifiche registrati successivamente. Per questo motivo, un backup senza un punto di ripristino definito non è un piano di emergenza completo. Bisogna considerare anche i pagamenti che possono essere confermati in ritardo e i dati inviati ai sistemi esterni.

Le regole per la preparazione di una copia sono illustrate nella documentazione del backup di PrestaShop. Per un negozio specifico, definisci inoltre chi ha verificato la possibilità di ripristino e come verranno concordate le modifiche sorte durante i lavori. Non dare per scontato fin dall’inizio un aggiornamento senza interruzioni.

Da cosa è composta la valutazione?

La valutazione può comprendere analisi e inventario, preparazione della copia, aggiornamento vero e proprio, adattamento del codice e del tema, test, passaggio e supporto dopo l’avvio. Separatamente vanno indicati le licenze, gli aggiornamenti a pagamento dei moduli esterni e le funzioni che richiedono ricostruzione.

Chiedi un ambito chiaro, le dipendenze e i criteri di conclusione. Un prezzo fisso ha senso per un lavoro ben identificato; in presenza di modifiche sconosciute può essere utile prima una fase di analisi. Non esiste un’unica cifra equa per ogni negozio contrassegnato come “PrestaShop 1.7” o “PrestaShop 8”.

Prepara la versione del negozio, il nome del tema e l’elenco delle integrazioni chiave. Su questa base si può iniziare a pianificare l’aggiornamento del negozio PrestaShop, definire le verifiche necessarie e preparare un ambito che possa essere rendicontato.

Verifica sostanziale: 13 settembre 2026. I requisiti di versione sono stati verificati nella documentazione di PrestaShop. La matrice decisionale è esemplificativa; il percorso finale e la compatibilità delle integrazioni vengono definiti per il negozio specifico.