Racconti di migrazione di ilDeposito.org #1

SPOILER: questo è un post discretamente tecnico 😅
(Primo capitolo di una serie sulla migrazione di ilDeposito.org)

Premessa: l'orgoglio dell'umanista informatico

Avere una passione (nel mio caso la musica di protesta) e l'informatica crea un connubio letale: poter ideare un progetto legato alla propria passione e avere gli strumenti tecnico-informatici per realizzarlo. Senza chiedere niente a nessuno, senza dover pagare niente (a parte i costi vivi di un server o cose di questo tipo, abbonamenti AI negli ultimi tempi).

È un potere pazzesco che però ha anche un aspetto negativo, almeno per come lo interpreto io: il perfezionismo. Se dovessi usare strumenti già pronti dovrei accontentarmi di quello che le piattaforme offrono. Invece posso fare da me. Non solo: mi sono anche sempre occupato dell'aspetto grafico, creativo, e anche questo è un problema: trasformare in codice html, css e js un template grafico non è sempre immediato, posto che ci sono di mezzo i limiti dei framework, etc.

Tutto questo un po' per farmi bello, un po' per mettere in evidenza come dietro un progetto come ilDeposito.org ci sia un immenso lavoro di progettazione, discussioni, musi che sbattono su muri, frustrazione e tante gioie 😀

Come era il sito e perché avevo la necessità di cambiarlo

Circa un mese fa ho pubblicato la nuova versione de ilDeposito.org. Uso il singolare perché, dal punto di vista tecnico, il sito lo gestisco io. Mi interessa raccontare il percorso che mi ha portato alla nuova versione, che vedete online, con le riflessioni sulle scelte tecniche, gli scogli incontrati, etc. Non perché siano particolarmente rilevanti ma perché ritengo che siano riflessioni a cui vanno incontro molti sviluppatori e condividere le esperienze credo sia fondamentale. E aggiungo subito che tutto quello di cui parlerò è stato ampiamente condiviso con un caro amico.

La vecchia versione era basata sul CMS open source Drupal, la versione 8.x. I CMS altro non sono che sistemi che permettono di gestire dei contenuti e renderli tramite un sito internet (il più famoso forse è Wordpress). Era il classico sito monolitico, in cui in un'unica applicazione erano compresi il frontend (la parte pubblica, quella che vedono normalmente gli utenti) e il backend (la parte redazionale, quella che serve per gestire i contenuti). Con una sorta di zona grigia condivisa, dato che in quella versione de ilDeposito.org gli utenti potevano registrarsi e creare e/o modificare i contenuti del sito. Tutto molto bello, peccato però che per molto tempo (anni!) non mi sono più occupato di aggiornare la piattaforma che intanto aveva fatto un salto di versione prima alla versione 9, poi alla 10 e infine alla 11 (e a fine 2026 dovrebbe uscire la 12).

Il risultato di questa mia noncuranza è stata l'impossibilità di aggiornare, con tutto quello che ne consegue in termini di sicurezza, ma anche l'impossibilità di portare avanti nuovi sviluppi perché i nuovi moduli non erano installabili, etc. Un inferno informatico. A questo aggiungiamo una necessità di effettuare un restyling grafico, che male non fa dopo un po' di anni.

Da qui la necessità di cercare il modo più indolore possibile per avere una nuova versione aggiornata e sicura del sito. Questi primi tentativi, premetto, sono stati fatti prima che si aprisse, almeno per me, il mondo dell'AI nello sviluppo del codice che, come scriverò in seguito, alla fine è stato il modo per uscirne senza impazzire (ricordo che il mio lavoro non è fare il programmatore, per fortuna).

Soluzione 1: il tentativo di aggiornare la piattaforma

Lavoro su Drupal dal 2011, posso dire di essere abbastanza esperto, in ogni caso è l'ambiente tecnologico in cui mi trovo meglio, la mia comfort zone. Il primo pensiero è stato: ok, proviamo semplicemente ad aggiornare il tutto da Drupal 8.x a Drupal 11. Facile a dirsi, non certo a farsi.

Un Drupal monolitico è quasi sempre integrato con decine di moduli che ne espandono le funzionalità. Belli, funzionanti, ma alcuni non hanno ricevuto aggiornamenti, quindi non erano aggiornabili. Risultato: il primo step consisteva in una serie di passaggi, gestiti da diversi branch su Git, che rimuovevano dal sito tutti i moduli extra e lasciavano solo ed esclusivamente quelli legati alla gestione del dato, né più né meno.

Fatto questo si arriva al secondo step: gestire le dipendenze incrociate tra l'aggiornamento delle versioni di Drupal, versioni di PHP (il linguaggio di programmazione con cui è scritto Drupal), versioni di Drush (il tool da linea di comando per Drupal), versioni di Composer (il gestore del codice di Drupal), il ginepraio delle configurazioni su file. Risultato: uno script in bash, basato come sempre su diversi branch di Git, che mi portava dal mio sito in Drupal 8.x a un sito pronto in Drupal 10 (al tempo non era ancora uscita la versione 11). Tutto pulito, perfetto, forse farraginoso, ma in fondo funzionante.

Per i più nerd, qui lo script completo:
👉 https://gist.github.com/arrubiu/44a220521834c75c8399189e865d749d

Poi però mi sono fermato, perché la bestia nera di Drupal non è gestire il backend ma realizzare il frontend, il tema grafico. Ma ne parleremo. In ogni caso, dopo questo lavoro è arrivata la temutissima stagnazione: mi sono bloccato e questo bel lavoro è rimasto fermo.

Soluzione 2: creare una nuova installazione Drupal e migrare i dati

L'insuccesso non mi ha fermato e ho quindi fatto un ragionamento diverso: invece che migrare il sito, cambiamo tattica: creo un sito ex novo su Drupal 11, utilizzando solo i moduli che servono - perché senza moduli su Drupal non si può stare - e poi importo i dati dal vecchio sito. Detto fatto ✅

Il flusso, ampiamente rodato, prevede i seguenti passaggi:

• nella vecchia installazione di Drupal si preparano, tramite Views (uno strumento di Drupal per creare elenchi di contenuti in vari formati), dei file JSON dove sono presenti tutti i contenuti, le tassonomie, gli utenti
• nella nuova installazione di Drupal si configurano le stesse entità (tipi di contenuto, tassonomie, utenti)
• tramite l'ottimo modulo Migrate si prendono i dati di questi JSON e li si importa nella nuova installazione

Tutto questo è stato realizzato ed ha funzionato per un bel po' di tempo. Soddisfazione alle stelle, è tutto pronto per passare alla seconda e decisamente più importante e impegnativa parte: la realizzazione del frontend, del tema grafico.

Primo tentativo di realizzazione frontend: il Drupal monolitico

Per evitare di uscire dalla più classica delle comfort zone, ho fatto un'indagine dei principali base theme di Drupal basati su Bootstrap, un noto framework CSS/JS.

Alla fine la scelta è ricaduta sul tema Radix, nella sua versione più nuova pesantemente basata sulla logica SDC (Single Directory Components). È tutto molto moderno, la logica SDC prevede che in una directory siano contenuti i template html, i fogli di stile CSS e l'eventuale codice Javascript.

Bello, professionale, una curva un po' ripida di apprendimento ma si gestisce senza troppi problemi. Mi sento un vero nerd 🥸 In parallelo ho iniziato a disegnare i template grafici, partendo dall'header e dal footer (ma su questo ci sarà un post specifico) e qui iniziano i primi mal di pancia: infilarsi nel sistema di theming di Drupal è sempre fastidioso: tanti livelli di interazione, uno sopra/sotto l'altro, logiche diverse, tutto molto complesso. Non è che siano cose che non so fare (le ho fatte per anni, anche per lavoro), sono cose che non ho più voglia di fare.

Per non rimanere impelagato nella famosa div soup di Drupal ("zuppa di div", ovvero codice Html pesantemente annidato e ridondante) ho pensato, grazie al pesante supporto dell'AI, di creare un sistema pseudo-decoupled: il modulo ildeposito_raw. Un sistema decoupled (disaccoppiato) si basa sull'idea che il backend e il frontend siano logicamente separati, l'esatto contrario del Drupal monolitico. Per evitare la complessità e farraginosità di Drupal ho pensato di creare un modulo, appunto ildeposito_raw, che prendesse i dati (i canti, gli autori) e li passasse come dati grezzi al template. Il vantaggio? Poter scrivere Html semplice, guidato anche dall'AI.

Ma non è stato sufficiente: non appena sono arrivato alle parti più articolate ecco che il demone Drupal è tornato a farsi sentire. E neanche l'aiuto dell'AI è stato sufficiente (magari la usavo male io, chissà). Anche in questo caso è arrivata la temutissima stagnazione: mi sono arenato, non riuscivo ad andare avanti.

A questo punto, anche dopo avere studiato alcune soluzioni, ho pensato che la soluzione fosse un vero sistema decoupled, pensando di abbandonare Drupal dopo 15 anni di onorato servizio. Quasi un sacrilegio. Ma d'altronde avere già dati JSON strutturati dei vecchi contenuti del sito rende facilmente fattibile la migrazione dei dati verso qualsiasi piattaforma. E si parte.

Soluzione 3: separiamo definitivamente il backend dal frontend

Separare frontend (tema grafico) e backend (gestione dei contenuti) è oramai una tecnica molto diffusa, che sembra anche molto comoda, per quanto nasconda delle insidie, in particolare se si prevede di spostare sul frontend il CRUD (gestione contenuti, ovvero create, read, update, delete). Ma oramai avevo deciso di togliere dal sito la possibilità per gli utenti di registrarsi, quindi la strada era spianata. Non me ne vogliano gli utenti de ilDeposito.org.

Essendo una tecnologia nuova per me ho studiato, letto, fatto grandi chiacchierate con Claude e Gemini per individuare il migliore strumento per il backend (dato anche il mio background informatico). I requisiti erano forse semplici:

• un sistema gratuito, open source (cioè il codice sorgente dello strumento è aperto, leggibile, in teoria modificabile)
• un sistema installabile in modalità self hosted (cioè installabile manualmente nel mio server). Cosa cambia? Che i dati stanno nel mio server, sono miei, li gestisco. Anche di questo ne parleremo in altri post
• un sistema abbastanza diffuso, conosciuto dall'AI (oramai quella barricata è superata, non si torna indietro. Ne parleremo)

Non sono requisiti particolarmente esotici, sono più o meno lo standard per chi si occupa di certe cose.

Dopo grandi elucubrazioni arriva la risposta? Directus! Spoiler: alla fine ho dovuto abbandonarlo.

Directus è uno strumento interessante: è totalmente agnostico rispetto al database (il contenitore dei contenuti). Un progetto interessante, l'ho installato, studiato e ho iniziato a lavorarci. Avevo anche iniziato a lavorare sul frontend, peccato che mentre lavoravo c'è stato l'aggiornamento dalla versione 11.x alla versione 12.x. E dalla nuova versione cambia la licenza, non sono più libero di usarla senza limiti, dovrei pagare, etc. Escluso.

Ma approfondiamo la questione, perché è importante. Questi CMS molto spesso possono essere usati in 2 modi:

• SaaS (Software as Service). Parolona, in realtà molto semplice: mi registro in una piattaforma e la uso. A volte pagando (spesso, a volte no)
• Self hosted. Come detto prima, significa che posso installare lo stesso software che potrei comprare online ma lo installo sul mio server, senza pagare niente (a parte i costi del server)

Detto così sembra semplice, il problema è che spesso le versioni self hosted sono limitate, non hanno le stesse funzionalità delle versioni che si comprano online (o si affittano, per essere più precisi), oppure bisogna pagare per avere sul proprio server le stesse caratteristiche.

Dopo questo necessario spiegone, resta il fatto che quando ho installato Directus nel mio computer e nel mio server l'ultima versione era la 11.x, senza limiti. Quando si passa alla versione 12.x viene fuori l'inghippo: non avevo più un uso illimitato dello strumento.

Sgomento, tristezza e rassegnazione. Come nel Monopoli si riparte dal via. Oramai l'opzione Drupal monolitico è tramontata (di zuppe di div ne ho avuto abbastanza, dal 2011 a oggi) e riparte l'analisi, lo scouting per creare il backend perfetto®️. Che ovviamente non esiste, ma in fondo sono un inguaribile ottimista.

Ripartono le chat incrociate coi chatbot di turno e alla fine arrivo alla soluzione che poi è andata online. E poi come finisce la storia? Beh la storia finisce che a luglio è andata online la nuova versione de ilDeposito.org, ma nei prossimi post, legati a questo tema, affronteremo due temi:

• la progettazione grafica
• la soluzione che infine è andata online

State in ascolto che arriverà tutto 😀