In che ordine aggiornare PrestaShop, PHP, tema e moduli senza rompere il negozio

Un negozio PrestaShop ha quattro componenti che invecchiano a ritmi diversi: il core, la versione di PHP del server, il tema e i moduli. Ognuno ha le sue versioni e ognuno richiede qualcosa agli altri. Se li aggiorni in un ordine qualsiasi, prima o poi arrivi a una combinazione che non funziona: un modulo che non si avvia con il nuovo PHP, un tema che chiama una funzione che il core non ha più o un core che non si installa perché il PHP è troppo vecchio.

La buona notizia è che l'ordine corretto si ricava quasi sempre da un'unica regola. Vediamola, insieme alla procedura completa.

La regola: non passare mai per una combinazione non supportata

Ogni versione di PrestaShop accetta un intervallo di versioni di PHP. Ogni modulo e ogni tema dichiarano (o dovrebbero dichiarare) con quali versioni di PrestaShop e di PHP funzionano. Aggiornare bene significa procedere per passi in modo che, dopo ogni passo, tutti i componenti restino entro ciò che supportano.

Questo ha una conseguenza pratica: quasi mai puoi saltare direttamente alla fine. Se il tuo negozio è su una versione vecchia con un PHP vecchio, e la versione di destinazione richiede un PHP più moderno che quella di partenza non supporta, ti serve un passaggio intermedio. A volte è una versione intermedia del core; a volte, un PHP intermedio accettato da entrambe.

Prima di toccare qualsiasi cosa: l'inventario

Prepara una tabella con tutto ciò che c'è nel negozio. Senza di essa, l'ordine è un tirare a indovinare.

• Versione esatta del core e versione di PHP usata dal sito (che può non essere la stessa del terminale del server).
• Tema: se è quello di serie, uno acquistato o uno su misura, se ha un tema figlio e chi lo mantiene.
• Moduli installati, con versione, autore e provenienza. Segna quelli che non usi più: non vanno aggiornati, vanno eliminati.
• Override nella cartella override/. Sono i primi a rompersi quando cambia il core, perché sostituiscono intere classi o metodi la cui firma potrebbe essere cambiata.
• Integrazioni esterne: ERP, gateway di pagamento, marketplace, corrieri. Ognuna è un modulo o uno script che dipende anch'esso dalle versioni.

Per ogni modulo, annota l'ultima versione compatibile con il tuo core attuale e con quello di destinazione. Quelli che non hanno una versione per la destinazione sono il vero lavoro del progetto: bisogna trovare un sostituto, chiederla all'autore o adattarli.

L'ordine che funziona nella maggior parte dei casi

1. Backup completo di file e database, e verifica che si possa ripristinare.
2. Elimina il superfluo. Moduli disinstallati ancora presenti su disco, moduli installati che nessuno usa, override orfani. Ogni componente che togli è un componente in meno da aggiornare e testare.
3. Aggiorna i moduli all'interno della tua versione attuale fino all'ultima versione che la supporta. Spesso quella stessa versione funziona già anche sul core di destinazione, e così il grande salto si fa con moduli moderni.
4. Aggiorna il tema all'ultima versione compatibile con il tuo core attuale, se il produttore la offre. Se è un tema su misura, controlla prima i template che cambiano di più tra le versioni: checkout, carrello e scheda prodotto.
5. Aggiorna il core, prima all'ultima revisione del tuo ramo e poi, se serve, al ramo successivo.
6. Cambia la versione di PHP con la più moderna supportata dal nuovo core e accettata da tutti i tuoi moduli.
7. Ricontrolla moduli e tema: alcuni hanno una versione specifica per il nuovo ramo che si può installare solo quando il core è già aggiornato.

Perché su una copia e non in produzione

Tutto quanto sopra si prova prima su una copia del negozio, con gli stessi file, lo stesso database e, se possibile, lo stesso PHP e la stessa configurazione del server. Sulla copia puoi sbagliare, tornare indietro e ripetere. In produzione, ogni tentativo fallito lo vedono i tuoi clienti.

Durante la prova, annota ogni passaggio con dettagli sufficienti per ripeterlo: quale modulo è stato aggiornato, in che ordine, quale impostazione è stata modificata a mano, quale file del tema è stato corretto. Il giorno del cambio non si improvvisa: si ripete l'elenco.

Cosa testare dopo ogni passaggio

• Home page, una categoria con filtri, una scheda con combinazioni e il motore di ricerca.
• Registrazione cliente, accesso e recupero password.
• Un ordine completo con ogni metodo di pagamento, nella modalità di test di ciascun gateway, fino a vedere l'ordine nello stato corretto.
• Le e-mail inviate al cliente (senza che arrivino davvero a nessuno: sulla copia la posta deve essere intercettata).
• Back office: elenco ordini, scheda di un ordine, fattura in PDF, modifica di un prodotto.
• Il log degli errori di PHP e quello di PrestaShop: conta anche ciò che non rompe la pagina.

Cosa si rompe più spesso

• Override che ridefiniscono metodi del core che sono cambiati. Il sintomo è un errore fatale subito dopo l'aggiornamento, a volte solo in una pagina specifica.
• Moduli di pagamento in versioni vecchie che usano hook o classi rimossi. Sono i più delicati, perché il guasto può trovarsi nel ritorno dal gateway: il cliente paga e l'ordine non viene creato.
• Template del tema che si aspettano variabili che il core non invia più o che hanno un nome diverso.
• Funzioni PHP rimosse o comportamenti che passano da avviso a errore con la nuova versione. Un modulo che funzionava con gli avvisi silenziati può smettere di funzionare del tutto.
• Cache che conservano classi compilate della versione precedente. Svuotarle fa parte della procedura, non è un trucco dell'ultimo minuto.

La finestra del cambio

Una volta fatta la prova, scegli quando applicarla in produzione:

• Un momento di poco traffico che puoi verificare nelle tue statistiche, non quello che tutti danno per scontato.
• Lontano da campagne e giorni di spedizioni intense. Non aggiornare alla vigilia dei saldi né un venerdì pomeriggio se il lunedì non c'è nessuno a controllare.
• Con le persone disponibili: chi esegue il cambio, chi testa i pagamenti e chi può chiamare l'hosting se serve.
• Con un piano di ritorno scritto: quale backup si ripristina, quanto tempo richiede e da quale sintomo si decide di tornare indietro. Se il negozio ha ricevuto ordini tra il backup e il ritorno, bisogna sapere come recuperarli.

Metti il negozio in manutenzione durante il cambio, lasciando l'accesso al tuo IP per testare, e non riaprirlo finché non hai completato lo stesso elenco di test della prova.

Dopo il cambio

I primi giorni sono di sorveglianza. Controlla il log degli errori, confronta gli ordini con gli incassi del gateway e chiedi al servizio clienti se arrivano richieste strane. Molti problemi di un aggiornamento non compaiono nella prima ora, ma quando qualcuno usa per la prima volta una funzione poco comune: un coupon specifico, un corriere che compare solo per certe province o una nota di credito.

E annota lo stato finale nell'inventario. Il prossimo aggiornamento parte da lì, e sarà molto più breve se non lasci passare anni tra uno e l'altro.

Come risolverlo in PrestaShop

In Rekire facciamo questo lavoro ogni giorno, da un aggiornamento di revisione all'interno dello stesso ramo fino a una migrazione tra versioni principali. Con un pacchetto di ore di assistenza (20 o 50 ore, in base alle dimensioni del negozio) prepariamo l'inventario di core, PHP, tema e moduli, allestiamo la copia di test, proviamo l'ordine di aggiornamento con il relativo elenco di test e applichiamo il cambio in produzione nella finestra che scegli tu. Le ore si consumano in base al lavoro reale, quindi puoi iniziare dall'inventario e decidere poi fin dove arrivare.