Cosa doveva essere su misura, e perché.
Il catalogo di un operatore di ritiri di benessere non rientra nei default dell'e-commerce. Un ritiro non è un prodotto — è un bundle vincolato a date che combina alloggio, pasti e istruzione in un'unica unità acquistabile. L'istruttore di riferimento non è l'autore di un prodotto; è la ragione per cui un ospite prenota. Il vocabolario sanscrito e i moduli di filosofia del marchio non sono un blog; sono un livello di contenuto che affianca la vetrina e dà alla decisione d'acquisto il suo contesto.
Abbiamo costruito la piattaforma su PrestaShop 1.7.4 alla fine del 2018, con quattro moduli specifici di dominio e un tema di default pesantemente personalizzato. Il modulo dei bundle di ritiro modellava offerte multi-data e multi-componente con selezione delle date e configurazione dei componenti — nulla nell'ecosistema PrestaShop ci si avvicinava. Il modulo di apprendimento del sanscrito aveva le proprie tabelle di database, route frontend e pannello di amministrazione: una superficie di vocabolario e filosofia che l'operatore poteva modificare indipendentemente dal catalogo. Un modulo rivenditori tracciava le agenzie partner B2B con record di contatto, Paese e valuta.
Il flusso di checkout è stato sovrascritto — 67 override di classi e controller al picco — perché gli acquisti di ritiri hanno regole di validazione diverse dai checkout di beni fisici. Non puoi acquistare due posti a un ritiro senza selezionare le date. Non puoi lasciare vuoto un campo componente e procedere al pagamento.
Piccole cose che hanno tenuto in vita la piattaforma.
Gli anni dal secondo al sesto non sono stati drammatici. Sostituzioni di fornitori di pagamento. Adeguamenti GDPR. Aggiunte di corrieri di spedizione. Aggiornamenti del runtime PHP integrati lungo l'ingaggio. Testi nuovi occasionali, nuovi formati di ritiro, nuovi partner B2B inseriti tramite il modulo rivenditori. Il tipo di manutenzione che non fa una pagina di progetto ma è il vero contenuto di un ingaggio di sette anni.
La maggior parte delle piattaforme su misura non sopravvive a questa fase. Il team che le ha costruite è andato avanti. I moduli non sono documentati. Gli override di classe sono codice misterioso. Ogni bump di dipendenza è un lancio di dadi.
La piattaforma è sopravvissuta perché c'erano le stesse persone. Quando una sostituzione di fornitore di pagamento ha richiesto modifiche all'override del checkout, l'ingegnere che aveva scritto l'override ha fatto la modifica. Quando un aggiornamento del runtime PHP ha rotto due costruttori di moduli, sapevamo quali costruttori controllare. La conoscenza istituzionale di un codice ha un valore cumulativo che emerge solo quando qualcosa si rompe — e qualcosa prima o poi si rompe sempre.
- F · 01Tipo di prodotto bundle di ritiro
- Bundle multi-componente vincolati a date (alloggio, pasti, istruzione) modellati in un modulo PrestaShop personalizzato. Nessun equivalente pronto all'uso.
- F · 02Livello di contenuto per l'apprendimento del sanscrito
- Separato dalla vetrina e dal blog: con tabelle di database, route frontend e pannello di amministrazione propri per i contenuti di vocabolario e filosofia.
- F · 03Livello rivenditori B2B
- Tracciamento delle agenzie partner con record di contatto, Paese e valuta. Prenotazioni instradate attraverso il modulo rivenditori senza toccare il flusso della vetrina pubblica.
- F · 04Flusso di checkout personalizzato
- 67 override di classi e controller al picco, che modellano regole di validazione specifiche dei ritiri — selezione delle date, configurazione dei componenti — che il checkout di default non impone.
- F · 05Manutenzione continua
- Sette anni di sostituzioni di fornitori di pagamento, adeguamenti GDPR, aggiornamenti di spedizione e aggiornamenti del runtime PHP — tutti gestiti dal team che ha scritto i moduli originali.
- F · 06Migrazione di major version in corso
- PrestaShop 1.7.4 → 1.7.8.11 completata in produzione; 1.7.8.11 → 8.2.3 in staging in fase avanzata. Ogni override ri-testato, a ogni modulo una passata di compatibilità con PHP 8.x. La migrazione è il lavoro che merita la cura nel tempo.
La migrazione che è in corso adesso.
La fine del ciclo di vita di PrestaShop 1.7 ha imposto una scelta nel 2025: ripiattaformare o migrare. Ripiattaformare significa buttare via sette anni di lavoro sui moduli specifici di dominio e ricominciare da zero su un nuovo stack. Abbiamo argomentato a favore della migrazione. L'operatore è stato d'accordo.
La migrazione procede in due fasi. La prima — PrestaShop 1.7.4 → 1.7.8.11 — è atterrata in anticipo ed è in produzione. La seconda — 1.7.8.11 → 8.2.3 — è il salto più difficile: PrestaShop 8 ha spostato più viste su Twig e ha cambiato il sistema di override quanto basta perché tutti i 67 override di classi e controller debbano essere ri-testati o rifattorizzati. Ogni modulo personalizzato ha bisogno di una passata di compatibilità con PHP 8.x.
Il solo ottobre 2025 ha prodotto 245 commit sul branch di migrazione a 8.2.3. Il lavoro procede in un ambiente di staging su branch con dati di produzione rispecchiati. Ogni flusso di checkout, ogni configurazione di bundle di ritiro, ogni route di contenuto sanscrito viene testato rispetto alla nuova versione prima che si apra la finestra di cutover. La migrazione è metodica e lenta perché la traccia di audit che lascia conta tanto quanto il codice aggiornato.
La ragione per cui la migrazione è possibile — e resta entro il budget — è che il team che la esegue ha scritto i moduli originali. Non abbiamo scoperto la complessità; la possedevamo già.
Le ragioni per restare con lo stesso team per l'aggiornamento.
Sette anni. Un solo team per tutto il tempo. Una migrazione di major version attualmente in staging in fase avanzata.
La piattaforma in produzione oggi gira su PrestaShop 1.7.8.11 con il modulo dei bundle di ritiro, la superficie di apprendimento del sanscrito, il livello rivenditori B2B e il flusso di checkout personalizzato intatti. Il branch 8.2.3 è il passo successivo — la migrazione che resiste a essere trattata come uno sprint di una settimana, e la parte che nessuno pianifica all'inizio di un ingaggio su piattaforma su misura.
Il valore di un lungo ingaggio su una piattaforma su misura non è la build iniziale. Chiunque può costruire la prima versione. Il valore è il contesto accumulato: sapere quale override è portante, quale assunzione di modulo andrà in frantumi sotto una nuova versione di framework, da quale classe PHP dipende il passo di pagamento in un modo che la documentazione non menziona. Quel contesto non si trasferisce a un nuovo team in un brief di migrazione. Vive nelle persone che hanno scritto il codice. La migrazione ora in staging è possibile — e sopravvivibile — perché lo stesso team possiede il codice originale.
Hanno scritto loro i moduli. Erano il team giusto per migrarli.