DrupalCon Vienna 2025: cosa abbiamo imparato (e cosa cambia per te)

Abbiamo passato quattro giorni alla DrupalCon Vienna 2025 (14-17 ottobre) seguendo oltre venti sessioni tecniche, workshop e BOF. Il messaggio più forte? Drupal non sta rincorrendo tendenze ma consolidando una leadership tecnica in tre aree critiche: AI enterprise-grade con governance reale, Canvas come primo CMS "design system native", e maturità operativa per progetti a scala.

Questo non è un report di marketing ma un resoconto pratico di cosa abbiamo visto funzionare in produzione, quali problemi rimangono aperti, e dove dovresti investire attenzione nei prossimi sei mesi. Per team italiani che pianificano progetti 2026, ci sono decisioni da prendere adesso, non dopo.

Ottobre a Vienna ha quel freddo secco che rende tutto più nitido. Perfetto per quattro giorni di immersione totale in quella che si è rivelata una delle DrupalCon più dense di contenuto tecnico degli ultimi anni. Non è stata una conferenza di annunci sensazionalistici, ma di demo funzionanti e problemi risolti sul campo, nonché quella rara combinazione di visione strategica e pragmatismo operativo che distingue le community mature da quelle in fase hype.

Tutti i video delle sessioni saranno presto disponibili nella playlist ufficiale DrupalCon Vienna 2025.

Il keynote di Dries Buytaert ha dato il tono: quattro pilastri (Canvas, AI, Orchestration, Site Templates, Marketplace) e una dichiarazione netta. L'AI è una tecnologia destinata a rimanere, indipendentemente dal fatto che la bolla finanziaria prima o poi esploderà. Drupal è uno dei CMS open-source meglio posizionati per sfruttarla. Niente difensivismo, niente "anche noi abbiamo l'AI", ma roadmap implementativa strategica e chiara.

Quello che ci ha colpito di più? La distanza tra annunci e realtà era minima. Canvas non è vaporware: è in alpha funzionante con agenzie che stanno già facendo pilot con clienti reali. L'AI non è un chatbot appiccicato: è architettura pensata per governance enterprise con observability production-grade. I site templates hanno superato la fase di concept: i primi sono già qui.

Organizziamo questo report per aree tematiche, non per cronologia. Quello che conta non è "cosa è stato detto martedì" ma "cosa cambia per i tuoi progetti del 2026".

Canvas: demo vera, risposte vere

Drupal Canvas (il nuovo nome di Experience Builder) è il nuovissimo builder visuale di Drupal che promette di semplificare e snellire il modo in cui disegniamo e costruiamo le pagine in Drupal. Ne abbiamo già parlato nel nostro articolo sulle innovazioni di Drupal CMS 2.0 e nella panoramica completa su Drupal AI, in cui abbiamo analizzato l'architettura e il posizionamento strategico. A Vienna abbiamo visto cosa significa portarlo in produzione, e soprattutto dove ci sono ancora gap.

La sessione "Drupal Canvas Unleashed" ha fatto sold-out con oltre 400 partecipanti. Il messaggio chiave: Canvas combina Single Directory Components (SDC) e blocks come componenti "backend", ma con Canvas non serve più sapere come funzionano una volta che sono stati sviluppati. 

I settings in Canvas sono le properties degli SDC, mentre in un pannello a sinistra si controllano gli slots, una nuova “entità” che permette di gestire l’alberatura dei componenti in layers, potenzialmente concatenati l’uno dentro l’altro. Inoltre, nelle configurazioni del theme c'è un setting per lasciare che Canvas gestisca le global regions come header e footer, importandole in pochi click in ogni nuova pagina. Davvero efficace ed intuitivo: chi conosce Figma o altri builder visuali come Framer e Webflow si ritroverà in un ambiente molto familiare.

Ma la feature più interessante? I Code Components, che supportano la scrittura di componenti React direttamente nel browser. Questi componenti possono utilizzare elementi e CSS components definiti in Canvas, supportano anche props per aggiungere dati dinamici (ad esempio, un titolo). In più, è anche possibile fare query tramite JSON:API per costruire componenti dinamici che recuperano dati dal backend.

Cosa funziona già:

• Content Templates per definire layout di content type strutturati (perfetto per landing pages)
• Global regions e componenti riutilizzabili
• AI (in beta) che permette di costruire code component direttamente via prompt
• Views supportate nativamente

Gap ancora aperti:

• Paragraphs e layout sono ancora work in progress
• Alcuni moduli contrib che funzionano solo su node non sono compatibili
• Alcuni contrib field type non funzionano ancora
• Multilingua non è supportato completamente
• Server-side rendering non è implementato (bloccato da implicazioni di security, non è assicurato supporto per qualunque server providers)
• API per estendere Canvas (non solo in termini di integrazione di moduli, ma anche di web apps embeddate in Canvas) ed offrire esperienze utente veramente ricche
• Sistema di permessi standard (ad es. per creare nuovi componenti o per usarne di esistenti)

La sessione "Strategies for Integrating Drupal Canvas in Your Existing Platform" ha dato indicazioni pratiche. Canvas crea un nuovo content type "canvas pages", quindi moduli che lavorano solo su node potrebbero avere problemi di compatibilità. Canvas è una React app sul frontend, la compilazione e il rendering nell'editor avvengono nel browser in real time.

Per sviluppatori frontend la sessione "JavaScript Frontend Development with Drupal Canvas: Beyond Decoupling" ha mostrato workflow avanzati. È possibile sviluppare componenti JS esterni e sincronizzarli con utility dedicate. C'è un workflow bidirezionale per passare da Drupal a Storybook e viceversa. Canvas supporta l'aggiunta di CSS globale per il preview. Ogni componente passa dati a Drupal, il componente è renderizzato con nuxt client-side, e i componenti esterni sono standard Vue component.

Takeaway pratico: Se stai pianificando progetti Drupal per Q1-Q2 2026, Canvas sarà production-ready (rilascio stable novembre 2025, default in Drupal CMS 2.0 da gennaio 2026). Nel budget diventerà fondamentale tenere in considerazione il tempo per lo sviluppo di component library, più che per l’implementazione di singole pagine. Il ROI è immediato per team con alto volume di page creation.

Design System nativo: finalmente un CMS che capisce il design

La sessione "Drupal, the first design-system native CMS" di Pierre Dureau (Beyris) ha presentato un cambio di paradigma che merita attenzione.

Infatti, in Drupal i theme presentano dei problemi storici non indifferenti: non sono condivisibili (un theme è per un progetto specifico), non sono plug-and-play (c'è sempre un template mancante), hanno una DX poco friendly.

La soluzione proposta: business agnostic coding. Come per il backend, il frontend deve essere disaccoppiato dal business tramite plugin, ovvero, un design deve essere concepito in modo agnostico da business e brand. Qui entrano i design system ben strutturati, che abilitano un grande punto di forza: “un design, molti prodotti”. 

E Drupal è un ecosistema che riesce in modo particolarmente efficace a sfruttare appieno un design system, in quanto un design strutturato, organizzato e ben descritto è un design che Drupal può comprendere ed usare facilmente (ne abbiamo parlato anche nel nostro recente articolo Design System e Drupal CMS).

In modo davvero interessante, nel talk viene introdotto un metodo che propone un'inversione del workflow Drupal tradizionale (site builder / backend dev → templates → frontend dev). Al contrario, ora è il frontend developer che fornisce plugin frontend modulari, e questo implica anche ownership per il frontend developer e YAML come strumento di lavoro principale.

Più di un mero esercizio stilistico, a supporto di questo metodo, di questo shift, ci sono funzionalità concrete già disponibili direttamente nel core di Drupal:

• breakpoints.yml per breakpoint images
• layouts.yml per layout grid system (layouts in Layout Builder)
• SDC per UI components
• icons.yml per icon packs

Certo, la copertura delle features è ancora piuttosto limitata. Tuttavia, in arrivo in Drupal 11.3 e 11.4 ci saranno importanti nuovi endopoint API dedicati al design, che permetteranno di alzare decisamente l’asticella e separare ulteriormente il theming dalla app di Drupal:

• Styles API con Utilities & Helpers (set di attributi HTML mutuamente esclusivi, auto-descrittivi, single-purpose e universali come Typography, Borders, Colors, Spacing, Elevation) e Themes & Modes (switch di branding predefinito, color scheme, accessibility settings)
• Design Tokens API con scoped values disponibili per override locali o globali, che diventano variabili CSS solo a runtime

Nonostante rimangano ancora diversi gap, questo talk pone l’accento su un obiettivo ambizioso ma realizzabile per la prima volta nella storia di Drupal: la possibilità di un design workflow completamente automatizzabile, dalla fase di design in Figma al rendering finale nel browser.

Ma non è stato l’unico talk focalizzato sulla coppia vincente Design System + Drupal. Davvero di rilievo è la sessione sul design system scalabile multi-brand di Nestlé, che ha mostrato un’implementazione reale. In questo caso studio si è parlato di riorganizzazione e progettazione del design system su tre livelli: core, ui components, brand overrides. 

Questa struttura si è rivelata fondamentale tanto per gestire la complessità di decine di brand diversi, quanto per dare una coerenza complessiva all’ecosistema di brand. Il sistema di theming Drupal basato su starterkit ha garantito deploy rapidi, update efficienti, e possibilità di istanziare nuovi siti in giorni invece che settimane. Ora, oltre 100 siti sviluppati in Drupal adottano questo approccio.

Takeaway pratico: Se stai costruendo o ripensando il tuo design system, considera approccio "design system first" invece che "Drupal theme first". L'investimento iniziale è maggiore ma la scalabilità e manutenibilità sono ordini di grandezza migliori. Per organizzazioni multi-brand è praticamente obbligatorio.

Accessibilità digitale: EAA e AI

Uno dei vantaggi principali di un design system è l’ottimizzazione e la coerenza dell’esperienza utente. Ma oggi, il design system è anche uno strumento strategico per essere conformi all’European Accessibility Act. Due talk hanno affrontato il tema dell’accessibilità, ed in particolare la sessione "AI in EAA" ha esplorato come l'AI possa supportare compliance con gli standard di accessibilità, sempre più critici con l'EAA in vigore da giugno 2025. 

L'AI può accelerare QA teams (crawling automatici), content editor (sommari, alt-text automatici, text editors intelligenti), designers (analisi colori e contrasti, object recognition, suggerimenti proprietà e stati ARIA) e developer (linting tools, IDE extensions, autocomplete per creare componenti accessibili) nell’intercettare problemi di accessibilità. 

Tuttavia, non può sostituire il vero testing umano. Anche in quest’ambito infatti, è fondamentale mitigare i rischi di eccesso di fiducia nell’AI, mantenendo la supervisione umana per superare limiti e bias dei tool automatici, come particolarità culturali e linguistiche e la sensibilità culturale, particolarità linguistiche e interpretazioni errate del contesto.

Fondamentale è in ogni caso la comprensione della tematica dell’accessibilità, non più un elemento accessorio, ma tanto un obbligo quanto un’opportunità per il business. Abbiamo approfondito il tema in due risorse chiave: il whitepaper Accessibilità e Design System e la checklist operativa all’accessibilità.

Takeaway pratico: Per molte organizzazioni, l’accessibilità non è ancora una priorità chiara. Tool automatici ed AI possono offrire un supporto significativo , ma l’educazione sui requisiti, la formazione interna, la comunicazione sono dei pilastri imprescindibili. Per essere davvero in regola, e per innestare davvero l’accessibilità nel DNA aziendale serve un approccio che integri l’accessibilità fin dalla progettazione: un metodo “design-to-code” che unisca interventi tecnici, formazione e cultura, che solo un partner specializzato può orchestrare.

AI Enterprise: governance prima di tutto

Abbiamo già scritto un articolo approfondito su Drupal AI analizzando features come generazione di contenuti, gestione del contesto, agenti autonomi e observability. A Vienna abbiamo visto implementazioni concrete e scoperto pattern che funzionano (e alcuni che no).

La sessione "The AI Agent Swarm has come to Drupal Canvas" ha mostrato integrazioni pratiche. Canvas template agent può costruire landing page intere assemblando componenti e l'AI beta configurata in Canvas permette di costruire code component via prompt (alcune impostazioni sono preconfigurate per accelerare l’adoption, ma è tutto personalizzabile).

La sessione ha anche esplorato come gli agents possano essere usati ovunque in Drupal per task piccoli o grandi, anche costruendo siti da zero con tool esterni via MCP (Model Context Protocol), tutto senza scrivere una riga di codice.

Per un utilizzo efficace degli LLM, “context is king”. Nel nostro precedente articolo, abbiamo esaminato la possibilità di definire un contesto per determinate azioni richiamabili tramite i Field Widget Actions. Questo sistema era ancora abbastanza macchinoso ed embrionale.

Un bel salto in avanti in tal senso è rappresentato dal Context Control Center, che permette di definire in modo centralizzato tutte le informazioni di contesto, come il proprio brand, persona e topic (in modo del tutto simile a quanto avviene in Claude Code o Copilot tramite files claude.md o agents.md, ma direttamente nella UI di Drupal). 

Inoltre, la centralizzazione dei contesti permette una governance decisamente più efficace. I diversi contesti sono poi facilmente richiamabili ed utilizzabili dalle diverse features ed agenti AI di Drupal. Se vuoi approfondire il tema del Context Engineering, ti rimandiamo all’interessantissimo talk di Enrico Zimuel durante il nostro evento dedicato alla GenAI.

Pattern che funziona. AI per content generation con supervisione umana per l’approvazione (Human in the Loop): l'AI crea un draft, una persona revisiona e approva prima della pubblicazione. Questo approccio risolve il trade-off tra velocità e controllo, e si sposa con la filosofia di Drupal in cui l’AI potenzia le persone, non le sostituisce.

Pattern che non funziona ancora bene: Full automation senza supervisione umana. Anche con Context Control Center ben configurato, l'AI può generare contenuti che tecnicamente rispettano le linee guida ma hanno sfumature sbagliate che solo un umano può cogliere. La full automation rischia quindi di non essere in linea con il livello di qualità del brand e la supervisione umana è fortemente raccomandata.

Takeaway pratico: Investi in AI per accelerare execution (drafting, ricerca, assembly), non per sostituire decision-making strategico. Il Context Control Center è il differenziatore chiave: senza governance centralizzata, l'AI enterprise scala male e introduce rischi. Budget tempo per configurazione iniziale robusta del Context Control Center, non pensare sia "plug and play".

DevOps e Release Management: lezioni dal campo

Alcune delle sessioni più dense di valore pratico erano su DevOps, CI/CD e release management: topics che fanno davvero la differenza tra progetti che scalano e progetti che collassano.

GitHub Actions + Docker + Cypress = CI/CD Nirvana

Nel talk viene descritta una configurazione ideale (il “CI/CD Nirvana”) per il processo di sviluppo: tool per sviluppo locale che automatizzano QA (grumPHP), visual regression test (BackstopJS), e2e test (Cypress), e audit di sicurezza. Questi stessi tool devono essere usati anche in CI per garantire rilascio di codice sicuro e senza regressioni.

Su GitHub questo è possibile con GitHub Actions. L'ideale è scrivere le proprie custom Actions, personalizzate per il caso d’uso specifico. In questo modo, i vantaggi ottenuti sono evidenti: eviti di utilizzare immagini Docker con software non necessario, puoi inserire tool specifici (es di debug), hai pieno controllo di cosa viene deployato. 

Ma è imperativo prestare molta attenzione alle implicazioni di sicurezza. Le GitHub Actions possono agire anche su codice in production e bisogna quindi limitarne l’accesso, le chiavi ssh devono essere secretate, occorre molta attenzione alle Actions di terze parti e dump di database. Come sempre, è fondamentale programmare audit e verifiche regolari del codice.

Mastering the Release Flow: 5 anni di continuous improvement

Caso studio molto istruttivo che include una istanza Drupal che distribuisce contenuti a 5 React apps, 20 servizi esterni connessi, 40 paesi con fino a 3 lingue ciascuno (il multilingual era a dir poco essenziale in questo progetto), 13.000 step di test distribuiti su 700 Behat feature files. 

I test in particolare hanno seguito un approccio molto rigoroso: erano strutturati in aderenza alle user journeys identificate, separando production e non-production tests, funzionalità core e country-specific, runnando tutte le notti. L’obiettivo? Identificare bugs ed anomalie prima degli utenti (e del cliente).

Nonostante la meticolosità, alcuni problemi emergenti hanno reso evidente che non era comunque sufficiente. In particolare i problemi incontrati dal team sono:

• Behat non è più sviluppato attivamente
• L'estensione Mink ha avuto a lungo un bug critico per le ultime versioni di Chrome (non fixato per 3 mesi)
• I test notturni su AWS duravano ormai più di 8 ore

Per superare questi limiti, il team ha creato un nuovo framework chiamato Cuppet che combina Cucumber (per non riscrivere i test) e Puppeteer (mantenuto attivamente da Google), basato su NodeJS.

I nostri takeaways da questo case studies?

• Se è “doloroso”, automatizzalo o risolvilo
• L'eccellenza operativa non è opzionale
• Make it work → make it right → make it fast (in quest'ordine, in questo caso studio il processo è durato ben 5 anni di miglioramenti iterativi)
• L'affidabilità è più importante delle nuove feature (cura il debito tecnico)
• Essere una “brava persona” è più importante delle skill tecniche, ancora di più in un mondo in cui tutti interagiscono con l’AI, ma in cui gli sviluppatori e gli utenti finali sono sempre persone.

Questo ultimo punto è emerso in diverse sessioni. Il keynote "Neurodiversity: An Underrated Superpower in Business" ha aperto il secondo giorno con discussione sulla neurodiversità e su come capacità peculiari di persone spesso messe in disparte possano portare contributi preziosi a team e organizzazioni.

Testing in Era AI

La sessione "Test All the Things" ha sottolineato che con l'AI che genera sempre più codice, il testing assume importanza ancora maggiore. Gli LLM rendono il coding alla portata di chiunque, anche di chi non ha competenze pregresse, sviluppando un falso senso di sicurezza. L’affidamento crescente a questi tool aumenta la probabilità di difetti o comportamenti imprevisti difficili da individuare.

Molto interessante è la panoramica su diversi approcci al testing in ambienti differenti, ad esempio:

• Eseguire test in un ambiente che replica la produzione garantisce un’elevata fedeltà, ma è un processo complesso, con implicazioni legate alla privacy e tempi lunghi, soprattutto in presenza di database di grandi dimensioni
• Installare sito con contenuti di test risulta invece molto più rapido e gestibile, ideale per cicli di sviluppo e verifica più agili, a scapito necessariamente della fedeltà all’ambiente in produzione

La static code analysis (PHPStan, psalm) è strumento valido per prevenire bug e mantenere sotto controllo la qualità complessiva del codice. Il workflow descritto nel talk è molto simile a quello che adottiamo in SparkFabrik, confermandone quindi la qualità, con la differenza che da quest’anno abbiamo adottato Symfony Panther per i behavioural tests, sostituendo Behat. Interessante anche l’accenno a Pa11y per l’analisi dell’accessibilità, strumento spesso sottovalutato ma di grande supporto per garantire conformità agli standard ed esperienze inclusive.

Takeaway pratico: Se stai adottando AI per la code generation, investi proporzionalmente di più in test automation e static analysis. Il codice AI-generated funziona spesso ma ha edge case inaspettati che solo test robusti cattureranno.

Security by Design: da requisito a cultura

In SparkFabrik, il tema della sicurezza ci sta particolarmente a cuore. Oltre ad essere un requisito normativo per molte aziende, la sicurezza è fondamentale per proteggere dati, fiducia degli utenti e reputazione online delle aziende.

La sessione "Secure by Design: Integrating Security into Drupal Development" ha presentato una valida overview sull'approccio “secure by design”, con indicazioni teoriche e pratiche delle strategie da mettere in atto per garantire la sicurezza di siti e portali sviluppati in Drupal, dai requisiti di business fino alle implementazioni tecniche. 

L'assunto di partenza: la Security deve essere intesa come core business requirement, non come “afterthought”. 

Ed in Drupal, questo assunto è preso molto seriamente, con un Security team dedicato che pubblica regolarmente avvisi di sicurezza. A ottobre 2023 è anche partita la Security by Design Initiative nella community Drupal, supportata dalla Cybersecurity and Infrastructure Security Agency degli USA, assieme a partner internazionali, compresi Stati europei come Germania e UK.

Nel talk vengono condivide indicazioni pratiche (anche molto tecniche e specifiche), tra cui citiamo:

• Implementare la sicurezza fin dalla fase requirements
• Code review periodico con focus security
• Automated security scanning in CI/CD
• Penetration testing regolare per progetti critici
• Security training per tutto il team (non solo developer)

Da citare anche la sessione "Better Debugging with Xdebug", in cui sono state presentate feature avanzate di debugging, comprese experimental features come "control sockets" per debuggare running processes, ed il concetto di "time traveling" per “andare indietro nel processo di esecuzione”.

Se vuoi approfondire i temi della sicurezza, guarda i nostri articoli sulla sicurezza e compliance con Drupal CMS, su Software Security e Cloud Security, sull’impatto di NIS2 e DORA nel Cloud Native (abbiamo anche creato una guida operativa completa).

Takeaway pratico: Per progetti enterprise, è importante mettere a budget tempo e risorse specifiche per attività di sicurezza (threat modeling, security testing, security reviews), idealmente un budget del 10-15% del tempo totale. Può sembrare tanto, ma è una frazione minima del costo di un security incident.

Marketplace e Site Templates: economics reali

Ryan Szrama di Centarro ha presentato "How to Sell Drupal Site Templates" con onestà rara. 

Anzitutto, cosa è un site template? È una combinazione di Drupal CMS, tema front-end, eventualmente anche un tema per il back-end, recipes che forniscono funzionalità e dei contenuti predefiniti che, assieme, creano un’installazione di Drupal su misura per uno specifico scopo e permettono di avviare rapidamente un nuovo progetto. Pensa ad esempio ad un Template per aziende che offrono SaaS, oppure a un sito ecommerce: use cases con necessità specifiche che possono essere impacchettate.

Commerce Kickstart è proprio uno dei primi Site Templates disponibili. Da distribuzione Drupal, è stato convertito in site template, arricchito da recipes per eCommerce, con esperienza di checkout moderna, diverse opzioni di configurazione e semplificazione dell’installazione. 

L’appeal dei Site Templates è abbastanza chiara: fornire una soluzione specifica ad un problema specifico. Anche dal punto di vista dell’offerta dovrebbe essere una strategia di vendita “migliore”, o almeno più immediata e diretta, rispetto ad un’idea di progetto, una “soluzione astratta”. Qui si innestano i punti più interessanti e pragmatici del talk: i punti critici e l’esperienza fino ad ora.

Tre sono i punti più critici:

• Nella pratica, come e dove pubblicare un site template? Attualmente infatti non c’è ancora un marketplace centralizzato su drupal.org, non c’è un sistema di gestione delle transazioni, e neanche di distribuzione dei files. Affinché i templates decollino, è fondamentale trovare una risposta operativa, evitando che si debbano gestire manualmente e individualmente gli acquisti.
• Come proteggere la proprietà intellettuale quando distribuisci l'intero prodotto come codice? Tema caldissimo, ed anche qui non vi è una risposta chiara.
• Ma il punto prioritario è: come convincere un cliente reale a comprare un Site Template? Il focus è su questo punto, testando la vendita sul campo. La value proposition su cui si sta facendo leva è il risparmio monetario e di tempo per il cliente finale, accettando però il trade-off di assenza di personalizzazione (prodotto “off the shelf”). Importante disclaimer, allo stato attuale non è stata conclusa ancora alcuna vendita (ai prospect non era chiaro cosa stessero comprando e le richieste viravano su necessità di coaching, personalizzazione, servizi dedicati).

Affinché la vendita dei Site Templates sia sostenibile, sono quindi fondamentali tre cose: un modo per distribuirli efficacemente, e comunicazione chiara su cosa include il pacchetto. 

A riguardo, la sessione "Decision-making at Scale: Drupal Marketplace Process Behind the Scene" ha mostrato come un committee di 12 persone si è occupata di decidere se Drupal dovesse creare un marketplace per site templates (un processo durato 14 settimane). La risposta è positiva, con un rilascio graduale. 

Nella pagina ufficiale della Drupal Marketplace Initiative, viene dettagliato il piano complessivo su Site Templates e Drupal Marketplace: 

• entro DrupalCon Vienna, un pilot con il semplice rilascio di 1-2 templates;
• entro DrupalCon Chicago (Marzo 2026), rilascio di un MVP del Marketplace, con 10-15 templates, sia gratuiti sia a pagamento;
• inizialmente, i Site Template Makers saranno limitati ad alcuni Drupal Certified Partners selezionati, per poi espandere progressivamente ad altri makers;
• per i templates a pagamento occorrerà rispettare requisiti di pricing trasparente, garantire maintenance, avere termini di supporto chiari;
• l’MVP includerà esperimenti in termini di pricing models e di divisione delle revenues;
• si ipotizza che inizialmente il 10% dei ricavi andranno alla Drupal Association;
• in iterazioni future, il marketplace gestirà direttamente le transazioni e la divisione delle revenues potrebbe cambiare in 60% al creatore, 30% alla DA, 10% ad un fondo a supporto dell’ecosistema.

Takeaway pratico: Il marketplace lancerà ufficialmente nei prossimi mesi, e si evolverà gradualmente ma velocemente. Per agenzie, considera sviluppare template verticali (e-commerce, no-profit, education) per differenziarti. Il modello economico sta ancora emergendo ma il timing è ideale per early movers.

Orchestration e Architetture Composable

La sessione "From CMS to Platform: How to Build Future-Proof Digital Ecosystems with Drupal" ha presentato vision importante. Quando un cliente chiede un sito web, in realtà la richiesta nasconde spesso la necessità di un ecosistema digitale completo, composto di siti web, applicazioni, integrazioni con sistemi terzi per servizi specifici.

Nella Drupal Core Strategy pubblicata a luglio, Dries ha definito esplicitamente Drupal una "platform" perché parlare di CMS è ormai limitato. Drupal ha potenzialità per fungere da cuore di piattaforma digitale per svariati touchpoint.

In questo talk è stato portato anche un esempio, un progetto basato su NodeHive, ma l’architettura di base può essere generalizzata per qualunque piattaforma che sfrutti Drupal come unico backend headless, con un Orchestration layer che permetta di gestire i vari touchpoint. 

Come abbiamo discusso nel nostro articolo su architettura composable, questo approccio è sempre più rilevante per organizzazioni che devono servire esperienze su web, mobile app, digital signage, voice assistant ed altro ancora, contemporaneamente e coerentemente.

In termini di orchestrazione dei workflow, un’importante novità è il supporto di Drupal in tool di automazione no-code / low-code come Activepieces (orchestration platform open-source con licenza MIT). Questo è stato annunciato durante il Driesnote ed approfondito nell’articolo dedicato di Dries.

Takeaway pratico: Non pensare più "sito Drupal" ma "Drupal come content hub". Architetta fin dall'inizio per una content delivery multi-channel. Il costo iniziale è leggermente più alto ma la flessibilità futura è incomparabilmente maggiore.

Gestione del cambiamento di scope: l'arte di dire NO senza dire NO

Oltre ai talk tecnici, la sessione "Navigating Scope Creep" è stata particolarmente apprezzata dai project managers. Infatti, ha affrontato tema universale nei progetti software: lo scope creep, l'espansione incontrollata dei requisiti, delle funzionalità e dei deliverables di un progetto oltre quanto approvato inizialmente.

Tipicamente lo scope creep si manifesta durante alcune fasi: raccolta dei requisiti, feedback dei clienti, vicino al completamento del progetto (le modifiche all’ultimo minuto sono particolarmente rischiose), e quando cambiano gli stakeholders (ad esempio nuovi membri del team, che possono portare nuove idee).

Le cause principali? Obiettivi o requirements poco chiari, comunicazione inadeguata, desiderio di evitare il conflitto (probabilmente il problema più comune), ma anche framework normativi e di mercato in continua evoluzione.

Nel talk viene proposto un approccio chiaro: accetta il cambiamento dello scope, ma fallo in modo efficace. L’approccio si basa su tre pilastri:

1. Awareness: è fondamentale conoscere il progetto nel dettaglio, monitorare il comportamento stakeholder ed il processo di richiesta di modifica.
2. Allineamento: fin dalle prime fasi, occorre creare una visione condivisa degli obiettivi, allineare priorità, parlare di aspettative, formalizzare la documentazione sullo scope.
3. Processi chiari: implementa processi di Change Management chiari, non accettare richieste verbali, documenta richieste e decisioni, poni limiti chiari.
4. Evita incomprensioni: Comunica in modo aperto e trasparente (anche esprimendo il tuo disaccordo, motivandolo), coinvolgi il cliente nei test, spiega sfruttando wireframes e prototipi.

Ciliegina sulla torta: in conclusione sono state condivise quattro tattiche concrete.

• The alternative offer: possiamo lavorare sulla nuova richiesta, ma dovremo aggiustare la timeline e il budget.
• Priority shift: aggiungere la richiesta significa togliere qualcos’altro dal backlog, a cosa dobbiamo togliere priorità?
• Future release: pianifichiamo questa aggiunta per la fase due, dopo aver completato le funzionalità chiave.
• Data-driven approach: in base alla nostra analisi, questa aggiunta porterebbe poco valore, soprattutto se raffrontato al costo di sviluppo (se hai statistiche contro una feature, portale al tavolo).

Takeaway pratico: Investi nel formalizzare il Change Management Process fin dal kick-off. Sembra un costo iniziale, ma previene ore (o settimane) di rework e tensioni con gli stakeholder. Usa tool come AI notetaker per meeting notes automatiche che diventano "single source of truth" condivise da tutti.

Real Talk: Drupal vs Storyblok

Un’altra sessione è stata una ventata di onestà: "Why We Left Drupal, Tried Storyblok, and What Happened Next". Un’agenzia ha tentato il passaggio da Drupal a Storyblok, spinti dalla volontà di diversificare gli strumenti e dal marketing massivo di questo CMS alternativo. In breve? La nuova soluzione non si è rivelata all’altezza.

La frustrazione principale è stata l’assenza di funzionalità base date quasi per scontate in Drupal, come la costruzione di moduli, la complessità nel gestire URL e redirect, la gestione delle configurazioni (e relativo versioning) in Git. Il team si è essenzialmente ritrovato nella condizione di dover innovare in autonomia per replicare funzionalità basilari già disponibili in Drupal (“Abbiamo letteralmente ricostruito il Configuration Management di Drupal per Storyblok”).

Non meno importante, il tech stack limitato. Il team aveva scelto Storyblok + Next.js, data la loro expertise, ma Storyblok era ottimizzato per Vue.js. Come risultato, l’agenzia ha dovuto costruire in autonomia dei workaround, anche per sfruttare le funzionalità della nuova versione di Next.js rilasciata durante il progetto.

Funzionalità a parte, il supporto stesso di Storyblock non all'altezza delle aspettative, con risposte non tempestive ed indicazioni poco chiare che hanno causato importanti ritardi. Non si può fare affidamento neanche sulla community, essendo estremamente ridotta e poco ingaggiata. Essenzialmente, ogni problema richiede una soluzione custom.

La scoperta: Una tecnologia come Storyblok può essere utile in contesti molto specifici, ma per soluzioni enterprise, Drupal continua a rappresentare standard di alto livello. Solido, testato in oltre 20 anni di lavoro community, con soluzioni rodate che rischiamo di dare per scontate dimenticando che non tutti i CMS le hanno. 

Una tagline memorabile: "Product before marketing." Questo risuona con il tema generale della conferenza. Drupal non sta facendo marketing aggressivo ma sta consolidando il suo posizionamento come prodotto d’eccellenza in aree critiche che contano davvero per il business. Come abbiamo discusso nel nostro confronto tra CMS, Drupal eccelle dove complessità, governance e longevità sono requisiti primari.

Takeaway pratico: Se stai valutando alternative CMS, guarda oltre feature list sulla carta e l’UI scintillante. Fai domande dure: come gestisci multi-brand? Come gestisci configurazioni e versioning? Come garantisci il controllo degli accessi granulare? Come migri quando inevitabilmente dovrai? Come è il supporto e la community attorno all’ecosistema? Drupal ha risposte rodate, le alternative spesso hanno promesse.

Performance: HTTP/3 e ottimizzazioni network-level

Come si evince dal titolo "TCP Fast Open and HTTP/3: Network-Level Optimizations for Lightning-Fast Drupal" è stata un’interessante disamina sul funzionamento dello stack HTTP/3 e TCP e delle sue ottimizzazioni a livello di performance. Ovvero come risparmiare preziosi millisecondi con le giuste configurazioni, e un'attenzione ai possibili vettori di attacco.

Secondo i dati condivisi, tra i top 1000 siti, il 60% supporta HTTP/3, di cui l’85% via CDN (Cloudflare, Fastly, etc) ed il 15% direttamente. Per quanto riguarda Drupal nello specifico, Drupal.org, Acquia Cloud e Platform.sh/Upsun supportano HTTP/3.

Un talk tecnico, ma il messaggio chiave è chiaro: È tempo di abilitare HTTP/3.

Takeaway pratico: Se non hai ancora HTTP/3 abilitato, questo è il momento. I performance gains sono significativi e misurabili specialmente per connessioni mobili e applicazioni che richiedono bassa latenza. Controlla con il tuo hosting provider se è disponibile (Acquia, Platform.sh, Pantheon lo supportano tutti).

Conclusione: action items concreti per i tuoi progetti

Quattro giorni a Vienna hanno confermato una tesi: Drupal sta attraversando momento di rinnovamento tecnico profondo senza perdere l'affidabilità enterprise che lo caratterizza. Questa è combinazione rara e preziosa.

Per team italiani che pianificano progetti 2026, ecco action items concreti da considerare in modo attento.

Se stai pianificando nuovo progetto Drupal:

• Budget Canvas come authoring layer (stable a novembre 2025, default a gennaio 2026)
• Architetta per design system first, non per Drupal theme first
• Includi AI Readiness Assessment nella fase di discovery del progetto (introdurre funzionalità AI come il Context Control Center richiede pianificazione)
• Pianifica per composable architecture anche se parti con un singolo touchpoint

Se hai Drupal in produzione:

• Review delle pipeline di CI/CD per includere security scanning automatica
• Valuta la realizzazione di un pilot con Canvas, limitandoti a una sezione del sito (non full migration subito)
• Check della compliance per l’accessibilità in vista dei nuovi requisiti EAA (ma anche come nuova opportunità)
• Verifica il supporto per HTTP/3

Se sei agenzia o system integrator:

• Considera sviluppare site template verticale per tuo target market, non appena possibile (e preparati a venderlo come prodotto, non come soluzione)
• Investi in design system, riutilizzabile e coerente cross-project
• Evalua partnership per integrare soluzioni e features AI nella tua offerta

Se hai un team in-house:

• Proponi un pilot di Canvas, per favorire in futuro la creaione di un elevato volume di pagine e contenuti
• Se hai necessità di generazione di contenuti, sperimenta e definisci dei business case da impostare nel Context Control Center
• Fai una review del tuo change management process (riduci il problema dello scope creep, costa più del processo di formalizzazione)
• Pianifica training intensivo sul nuovo stack di features e strumenti (Canvas, tools AI, approccio al design system)

La sensazione uscendo da Vienna? Drupal ha fatto scelte architetturali nel 2015 (structured content, API-first, configuration management rigoroso) che allora sembravano overkill. Nel 2025, tali scelte risultano vincenti. Sono esattamente l'infrastruttura necessaria per AI enterprise-grade, visual page building senza sacrificare governance, e composable architecture scalabile.

Come ha detto Dries al keynote: "AI is the storm, but it's also the way through it." Drupal non sta evitando la tempesta. Sta navigando meglio di chiunque altro.

In SparkFabrik, combiniamo una profonda expertise tecnica su Drupal con competenze avanzate in AI integration, architetture composable e governance enterprise. I nostri servizi di sviluppo Drupal coprono l'intero spettro: da consulenza strategica sull'AI readiness della tua architettura attuale, a implementazione di soluzioni AI-powered custom, fino a sicurezza, supporto continuativo e ottimizzazione.

Se la tua organizzazione sta considerando l'adozione di AI per le sue iniziative digitali, ti invitiamo a:

1. Esplorare i nostri case study di implementazioni Drupal enterprise
2. Contattare il nostro team per una valutazione delle tue esigenze specifiche
3. Scoprire come la nostra suite di servizi Drupal può supportare la tua strategia AI

Questo articolo è parte della nostra serie dedicata a Drupal CMS. Per esplorare altri aspetti della piattaforma, vi invitiamo a consultare i nostri precedenti articoli su caratteristiche e vantaggi, confronto con le alternative, strategie di migrazione, sicurezza e compliance, architettura composable, Design System, Drupal headless omnicanale e panoramica e novità di Drupal AI.