Una call con chi ci lavorerà
Parli con le persone che lavoreranno al tuo portale: cosa ti blocca oggi, quali sono i tuoi obiettivi, come è fatto il portale. Ci servono anche alcune informazioni come versioni, ambienti, modo di lavorare.
Lavoriamo con Drupal dal 2010, dal primo progetto per ENI. Costruiamo nuovi siti e portali, prendiamo in carico e manteniamo quelli esistenti, li facciamo evolvere e li portiamo su versioni supportate. Prima di toccare il codice, capiamo cosa c'è e cosa serve.
Un Drupal monolitico, con contenuti e tema nella stessa applicazione, resta una scelta sensata se gli lasci spazio per crescere. Quando la base non regge, lo ricostruiamo una volta e da lì riprende a evolvere.
Un Drupal monolitico può continuare a crescere per anni, a patto che alcune basi siano a posto. Feel Florence, tra i casi più in basso, ne è un esempio.
Una versione supportata riceve aggiornamenti regolari, compresi quelli di sicurezza. Se la fine vita è vicina, conviene pianificare il passaggio prima di aggiungere nuove funzioni.
Titoli, testi, immagini e date stanno in campi distinti, non in blocchi di HTML scritto a mano. Così gli stessi contenuti possono alimentare nuove pagine o altri canali, per esempio un'app.
Cosa mostrare in una pagina e a quali utenti si decide nella configurazione di Drupal, non nei template del tema. Così il tema si occupa solo dell'aspetto e si può cambiare senza riscrivere le regole.
Dopo una prima call raccogliamo le idee in più scope plan: ciascuno definisce il perimetro di un obiettivo, cioè cosa serve agli utenti e al business e cosa entra nella prima versione. Da qui nasce la proposta.
Dopo l'avvio scriviamo la roadmap esecutiva: più precisa degli scope plan, ti dice subito dove restano incertezze. Si procede per milestone, di solito mensili, ognuna con una consegna in un ambiente di test: il codice e la sua documentazione. Ogni modifica al codice passa da una pipeline di Continuous Integration e Delivery.
La parte più lunga della vita di un portale comincia dopo la messa in produzione: aggiungere funzioni, aggiornare Drupal e i moduli, adattarlo a come cambia il lavoro di chi lo usa.
Che il portale arrivi da un altro fornitore o sia nato con noi, partiamo da ciò che ci racconti e, dove serve, da un assessment, cioè l'analisi completa del portale prima di intervenire. Poi lo facciamo crescere sulla base esistente, oppure lo ricostruiamo. Tra il 2024 e il 2025 abbiamo curato manutenzione ed evoluzione di un progetto Drupal di Fondimpresa, sulla base che avevamo ereditato. Dal 2026 curiamo la manutenzione della Rete civica del Comune di Firenze, alla cui migrazione avevamo già lavorato in parte.
Drupal 7, 8 e 9 sono arrivati a fine vita. Per Drupal 10 la fine è programmata per il 9 dicembre 2026. Dopo la fine vita una versione non riceve più rilasci, compresi quelli di sicurezza. Portiamo il tuo portale su una versione supportata, con un percorso che dipende da dove parti.
Se il tuo team sviluppa in proprio, possiamo affiancarlo: analizziamo un problema, un'architettura o una scelta tecnica e ti proponiamo come procedere. Puoi chiedercelo anche se non lavoriamo già insieme.
Parli con le persone che lavoreranno al tuo portale: cosa ti blocca oggi, quali sono i tuoi obiettivi, come è fatto il portale. Ci servono anche alcune informazioni come versioni, ambienti, modo di lavorare.
Due settimane di analisi, senza toccare il codice. Verifichiamo il codice su misura, i moduli contrib, come è organizzato il repository, gli interventi fuori standard sul database e il tema. Alla fine hai l'elenco dei bloccanti e una proposta. Il documento resta tuo, anche se non prosegui con noi. Se l'evolutiva non ha obiettivi definiti per milestone, l'assessment può entrare nel contratto di manutenzione.
Due settimane di sviluppo e test, poi il rilascio in produzione, spesso senza interrompere il servizio. Le richieste arrivano per email o con uno strumento di gestione delle richieste e si discutono negli incontri di stato avanzamento lavori, o SAL, dove vedi priorità e avanzamento con una cadenza che dipende dal progetto e dal cliente. Le milestone si usano quando gli obiettivi sono più ampi e definiti.
A ogni rilascio in produzione ricevi le note di rilascio, con i link a ciò che è stato rilasciato. Codice, documentazione e gli altri deliverable arrivano secondo il contratto di manutenzione. Stiamo lavorando per fare dei report sulle attività una parte standard di ogni progetto.
Drupal, Monolitico, UX e UI, Continuous Integration, Operations
Nel 2024 abbiamo rifatto su Drupal il portale turistico del Comune di Firenze. Ne abbiamo riprogettato l'interfaccia pensando prima di tutto allo smartphone, perché i turisti possano consultarlo con facilità. L'accessibilità la verifichiamo con MAUVE++.
Drupal, Monolitico, Operations, Continuous Integration
Nel 2022 siamo partiti da un assessment, l'analisi con cui verifichiamo se un portale può crescere sulla base che ha. Qui ha dato semaforo rosso: da lì abbiamo rifatto il portale, mantenendo il design approvato in precedenza. È online dal 2024.
Drupal, Next.js, Decoupled, Continuous Integration
Nel 2022 il digitale stava diventando centrale per Flexform, e al portale servivano nuovi strumenti. La scelta: contenuti su Drupal e frontend ricostruito in Next.js. Dal 2023 il portale cresce ogni anno con nuove funzioni per utenti e rivenditori.
Come indica il calendario ufficiale dei rilasci di Drupal, ogni versione ha una data di fine vita, dopo la quale non riceve più rilasci. A partire da Drupal 8 si aggiorna una versione alla volta: per esempio da 9 a 10, poi da 10 a 11.
Drupal 8 ha cambiato le fondamenta del CMS: il cuore poggia su componenti di Symfony, i temi usano il motore di template Twig al posto del sistema precedente. La configurazione vive in file che si possono esportare e versionare insieme al codice. Per questo da Drupal 7 non si aggiorna: si migrano contenuti e configurazione su un portale nuovo e si ricostruisce il tema. È una reingegnerizzazione: conviene progettarla già pronta per separare frontend e contenuti, se un giorno ti servirà.
Qui si aggiorna, senza migrare i contenuti, passando da una versione alla successiva fino a quella supportata. Il lavoro riguarda soprattutto il codice su misura, i moduli contrib e il tema.
Nella stessa settimana è prevista l'uscita di Drupal 12. Dopo il 9 dicembre Drupal 10 non avrà nuovi rilasci. Se il tuo portale è su Drupal 10, è il momento di pianificare il passaggio: quanto lavoro serve dipende dal portale, perciò lo stimiamo dopo averlo verificato.
Su drupal.org abbiamo sviluppato moduli contrib come Breadcrumb Manager e HTTP Client Manager. Abbiamo anche crediti su due security advisory, per Mosaik e Workflow.
Tra il 2011 e il 2017 abbiamo contribuito a organizzare cinque edizioni del Drupal Day.
Dal 2025 siamo tra gli organizzatori del DrupalCamp Italy, dove il 22 ottobre 2026 abbiamo rilasciato come open source la suite Page Delivery.
Se il tuo Drupal monolitico regge ma il frontend rallenta ogni novità, non serve rifarlo da zero. Il frontend si può separare da Drupal un passo alla volta, mentre i redattori continuano a lavorare come oggi. Quando conviene e come lo facciamo lo spieghiamo nella pagina sulle architetture decoupled.
Drupal è il nostro strumento principale, ma prima di proporlo guardiamo cosa deve fare il portale e chi lo userà ogni giorno. Tre casi dal nostro lavoro:
Se il tuo portale Drupal regge e non frena chi ci lavora, il consiglio più utile è spesso lasciarlo com'è e farlo crescere.
Dipende da cosa deve fare il portale. Per un portale complesso, con molti contenuti, più lingue, redazioni con permessi diversi e integrazioni con altri sistemi, Drupal è lo strumento che sceglieremmo anche oggi. Nel 2010 lo abbiamo adottato perché cercavamo un CMS open source, modulare e capace di reggere organizzazioni complesse: lo usiamo ancora per questo. Se il modello dei contenuti è semplice e la redazione è piccola, può bastare uno strumento più leggero: te lo diciamo prima di cominciare.
Non sempre. Con un assessment verifichiamo se la base può reggere la crescita. Se regge, la facciamo evolvere. Se non regge, conviene ricostruire una volta, come abbiamo fatto per i Vigili del Fuoco. Poi il portale cresce sulla nuova base.
Partiamo da ciò che ci racconti e da alcune informazioni sul portale: versioni, ambienti, modo di lavorare. Dove serve facciamo un assessment di due settimane, senza toccare il codice: verifichiamo codice su misura, moduli contrib, repository, database e tema. Ne esce un documento con i bloccanti e una proposta, che resta tuo anche se non prosegui con noi. Poi decidiamo insieme se far crescere il portale o ricostruirlo.
Da Drupal 7 serve una migrazione: contenuti e configurazione passano su un portale nuovo, con il tema ricostruito. È anche il momento di decidere come sarà il frontend. Se un giorno vorrai separarlo dai contenuti, conviene progettare la migrazione già pronta per farlo.
Sì, su richiesta: affianchiamo il tuo team interno, analizziamo un problema o un'architettura e ti proponiamo come procedere. Non serve avere già un progetto in corso con noi.
Il portale non dipende da una sola persona. Lavoriamo come un'unica squadra, ogni milestone si chiude con la sua documentazione e, quando serve, affianchiamo il tuo team interno.
Parliamo del tuo progetto, con chi lo progetterà