Una migrazione di versione maggiore raramente si gioca sul cuore di PrestaShop, che si aggiorna correttamente nella maggior parte dei casi. Si gioca sui vostri moduli. Su un negozio che ne conta quaranta, basta che uno solo tocchi il processo d’ordine e non sia più compatibile perché l’intera migrazione si blocchi.
L’audit dei moduli deve quindi precedere tutto il resto, preventivo compreso.
Cosa cambia davvero
PrestaShop 9 si appoggia a versioni più recenti di PHP e di Symfony, il che comporta tre famiglie di rotture.
Le rotture legate a PHP. Tipizzazione più severa, proprietà dinamiche deprecate, funzioni rimosse. Un modulo scritto cinque anni fa e mai ripreso produce errori fatali, non avvisi.
Le rotture legate al framework. I moduli che estendono controller Symfony o che dichiarano servizi devono seguire la nuova versione. È il caso dei moduli recenti e ben costruiti, paradossalmente più esposti di quelli puramente legacy.
Le rotture proprie di PrestaShop. Metodi rimossi dalle classi storiche, hook eliminati o rinominati, cambiamenti nei template del tema predefinito.
L’inventario, primo deliverable
Prima di qualsiasi manipolazione, producete una tabella con una riga per modulo e sei colonne.
- Nome tecnico e versione installata.
- Editore, e la sua esistenza attuale. Un editore scomparso è un modulo condannato.
- Data dell’ultimo aggiornamento disponibile. Oltre i diciotto mesi senza pubblicazione, considerate il modulo abbandonato salvo prova contraria.
- Compatibilità dichiarata con la versione di destinazione, distinguendo ciò che è scritto sulla scheda prodotto da ciò che è stato realmente testato.
- Criticità: il modulo tocca il pagamento, il processo d’ordine, il catalogo, oppure solo una visualizzazione secondaria?
- Presenza di override, visibile nella cartella delle sovrascritture. È il miglior indicatore di fragilità.
Questa tabella si compila in mezza giornata e determina tutto il resto del progetto.
Le quattro categorie
Ogni modulo rientra in una di esse, e il trattamento cambia.
Compatibile e mantenuto. Aggiornate e testate. È il caso più semplice, e raramente rappresenta la maggioranza.
Compatibilità dichiarata ma non verificata. La menzione sulla scheda prodotto non vale collaudo. Questi moduli vanno testati per primi, perché un’incompatibilità scoperta tardi costa un rinvio.
Abbandonato. Due uscite: trovare un sostituto, oppure far riprendere il codice. La ripresa ha senso solo se la funzionalità è specifica della vostra attività.
Sostituibile con il nativo. Categoria sistematicamente sottovalutata. Ogni versione maggiore integra funzioni che prima esistevano sotto forma di modulo. Una migrazione è il momento giusto per disinstallare ciò che non serve più.
Negli audit reali, quest’ultima selezione toglie spesso dai cinque ai dieci moduli dalla lista, alleggerendo altrettanto il progetto.
Controllo Link Rotti PrestaShop 8 e 9 — Link Morti e Immagini MancantiTrova i link morti e le immagini rotte prima dei tuoi clienti€59.00
Le trappole tecniche più frequenti
Per gli sviluppatori e le agenzie, quattro rotture tornano costantemente sui moduli da riprendere.
Il metodo di traduzione disponibile direttamente sui controller è sparito: bisogna passare dall’istanza del modulo. Le sovrascritture di metodi la cui firma è cambiata producono errori di compatibilità, in particolare sui metodi di rendering usati per le risposte asincrone. Le chiamate asincrone ai controller di amministrazione storici hanno cambiato forma ed esigono che i parametri siano passati diversamente. E i moduli che scrivevano direttamente in tabelle del cuore si scontrano con l’evoluzione dello schema.
Nessuna di queste correzioni è complessa presa da sola. Il costo viene dal numero.
L’ambiente di collaudo
Non negoziabile, eppure regolarmente saltato.
Deve poggiare su una copia recente della base di produzione, non su un set dimostrativo. La maggior parte delle incompatibilità appare su dati reali: prodotti con cento combinazioni, clienti con indirizzi incompleti, ordini in stati dimenticati.
Due precauzioni: anonimizzate i dati dei clienti prima di copiare, e disattivate ogni invio di email da quell’ambiente. Un test di migrazione che invia duemila email di cambio stato a clienti veri è una storia vera e frequente.
Il piano di test
Testate percorsi, non pagine. Sei percorsi coprono l’essenziale.
Un ordine completo come visitatore non registrato, con pagamento reale in ambiente di test. Un ordine con un account esistente e un indirizzo salvato. Un’aggiunta al carrello da una pagina categoria con filtri attivi. Una ricerca interna seguita da un acquisto. Un reso o una richiesta di assistenza. E lato amministrazione, la creazione di un prodotto con combinazioni e la validazione di un ordine.
Ogni percorso va giocato su desktop e su mobile. Calcolate una giornata per l’insieme, da rifare dopo ogni correzione significativa.
Il passaggio e il dopo
Prevedete la migrazione fuori dai periodi commerciali, con una finestra di ritorno indietro definita e testata. Un backup mai ripristinato non conta.
Nei giorni successivi, si impongono tre controlli. I registri di errore del server, che rivelano le incompatibilità che il collaudo non ha incontrato. I link e le immagini rotti, perché un cambio di versione può toccare i percorsi delle immagini e le URL riscritte. E l’andamento degli ordini, da confrontare con il livello abituale: un calo brusco segnala un blocco nel processo d’ordine che nessuno ha segnalato.
Su quest’ultimo punto, il Verificatore di Link Morti per PrestaShop è utile in fase di collaudo come dopo il passaggio: rileva i link interni rotti e le immagini mancanti che la migrazione può aver prodotto, su PrestaShop 8 come su PrestaShop 9.