Drupal è una piattaforma open source per creare e gestire siti web, portali e applicazioni digitali. Definirlo semplicemente “un CMS alternativo a WordPress”, però, oggi è riduttivo.
Il primo punto da chiarire è che Core e Drupal CMS non sono esattamente la stessa cosa. Il Core è la base flessibile e API-first sulla quale sviluppatori e agenzie possono costruire progetti molto personalizzati. Drupal CMS utilizza quella stessa base, ma aggiunge un punto di partenza più completo, strumenti visuali e configurazioni pensate per ridurre il lavoro necessario nelle fasi iniziali.
Questa distinzione è importante soprattutto se stai valutando la piattaforma per un nuovo progetto. Dà il meglio quando contenuti strutturati, permessi, workflow, multilingua e integrazioni hanno un peso reale. Per un semplice sito vetrina gestito da poche persone, invece, tutta questa flessibilità può tradursi in una complessità che non serve.
Se vuoi prima inquadrare la categoria, nella nostra guida su cos’è un CMS spieghiamo come funzionano i sistemi di gestione dei contenuti e in cosa differiscono da website builder e piattaforme SaaS. Qui ci concentriamo sull’ecosistema, sull’architettura, sugli utilizzi e sui criteri che aiutano a capire quando può essere una scelta sensata.
Cos’è Drupal oggi: Core e Drupal CMS non sono la stessa cosa
Per anni il nome Drupal ha indicato soprattutto il progetto open source che oggi chiamiamo Core. L’evoluzione più recente ha aggiunto un secondo livello: Drupal CMS.
La distinzione ufficiale è abbastanza netta: il Core è il framework/CMS di base altamente configurabile; Drupal CMS è un prodotto pronto all’uso costruito sopra il Core. Non sono quindi due tecnologie concorrenti.
Drupal Core: la base per costruire progetti su misura
Il Core contiene le fondamenta del sistema: gestione dei contenuti, utenti, ruoli, permessi, campi, tassonomie, moduli, temi, API e gran parte dei meccanismi sui quali viene costruito il sito.
È il punto di partenza più naturale quando il progetto richiede controllo sull’architettura.
Immagina, per esempio, un portale immobiliare. Un contenuto “Immobile” può avere prezzo, metratura, comune, coordinate, classe energetica, immagini, agente responsabile e relazioni con altri contenuti. Un redattore non vede semplicemente un grande editor di testo: compila una struttura coerente che il sistema può riutilizzare in schede, risultati di ricerca, mappe, API o applicazioni esterne.
È questo modo di modellare le informazioni che distingue la piattaforma da molti CMS utilizzati principalmente per assemblare pagine.
Drupal CMS: il prodotto ready-to-use costruito sul Core
Drupal CMS parte dallo stesso motore, ma cerca di ridurre il lavoro necessario per arrivare a un sito utilizzabile.
Integra un’esperienza più pronta per la costruzione visuale delle pagine, configurazioni predefinite, componenti e Recipes che permettono di attivare più rapidamente funzionalità comuni.
Il punto da non fraintendere è questo: non sostituisce il Core. È una distribuzione/prodotto costruito sulla stessa piattaforma e destinato soprattutto a chi vuole partire con più elementi già assemblati.
La stessa documentazione ufficiale su Drupal Core e Drupal CMS mantiene questa separazione.
Versioni attuali, Drupal 7 EOL e cosa cambia con Drupal 12
Il numero di versione conta soprattutto per supporto, compatibilità e sicurezza, non come argomento per scegliere un CMS.
Al momento dell’ultimo controllo, il ramo stabile del Core è la serie 11.4, mentre Drupal CMS è nella serie 2.1. Per verificare patch e release più recenti conviene consultare direttamente le release del Core e quelle di Drupal CMS, perché le patch cambiano molto più rapidamente di una guida editoriale.
Un confine molto più importante riguarda Drupal 7, che ha terminato il supporto ufficiale il 5 gennaio 2025. Un sito ancora basato su quella generazione non dovrebbe quindi essere considerato equivalente a un progetto moderno basato sui rami supportati.
Drupal 12 rappresenta la major successiva. Introduce requisiti tecnici aggiornati, ma la logica corretta non è inseguire automaticamente il numero più alto: per un progetto reale vanno considerate stabilità, finestra di supporto, compatibilità dei moduli utilizzati e percorso di aggiornamento.
Come funziona Drupal
Per capire il sistema bisogna cambiare leggermente prospettiva. Una pagina non è necessariamente l’unità centrale del progetto: prima vengono i dati e le loro relazioni, poi le diverse modalità con cui quei dati vengono mostrati.
Questa impostazione può sembrare più astratta all’inizio, ma diventa molto potente quando il sito cresce.
Content type, field e tassonomie: il modello dei contenuti
Un content type descrive una categoria di contenuto con una propria struttura.
Un magazine potrebbe avere, per esempio, “Articolo”, “Autore” e “Recensione”. Un portale turistico potrebbe avere “Località”, “Hotel”, “Evento” e “Itinerario”.
A ciascun tipo puoi aggiungere campi specifici: testo, data, immagine, numero, indirizzo, file, riferimento a un altro contenuto e così via. Le tassonomie permettono poi di classificare le informazioni attraverso vocabolari e termini anche gerarchici.
Il vantaggio pratico è che l’informazione non rimane intrappolata nel layout della pagina.
Se il prezzo di un prodotto è un campo separato, puoi ordinarlo, filtrarlo, esporlo tramite API o riutilizzarlo altrove. Se invece prezzo, caratteristiche e descrizione sono semplicemente scritti dentro un unico blocco HTML, queste operazioni diventano molto meno naturali.
È uno dei motivi per cui questa architettura ha senso nei progetti con contenuti complessi e molte relazioni.
Moduli, temi e Recipes: come si estende il sistema
L’architettura è modulare.
I moduli aggiungono o modificano funzionalità. I temi governano la presentazione. Il Core contiene già numerosi componenti, mentre l’ecosistema contrib mette a disposizione progetti mantenuti dalla community.
Le Recipes hanno un ruolo differente. Servono a descrivere e applicare configurazioni ripetibili: possono installare dipendenze, attivare moduli e predisporre una determinata funzionalità senza richiedere che ogni passaggio venga ripetuto manualmente.
Questo approccio è utile soprattutto per agenzie e team che devono ricreare pattern già sperimentati. Invece di ricordare ogni volta quali estensioni installare e quali impostazioni modificare, parte della configurazione può diventare riutilizzabile.
Utenti, ruoli, permessi e workflow editoriali
La gestione degli accessi è uno dei punti in cui l’architettura diventa particolarmente interessante.
I permessi descrivono le singole azioni che un utente può compiere, mentre i ruoli aggregano più permessi. Questo permette di modellare situazioni molto più precise del semplice “amministratore oppure redattore”.
Un sito potrebbe avere, per esempio, autori che creano contenuti senza pubblicarli, revisori autorizzati a modificarli, responsabili che approvano solo determinate sezioni e amministratori tecnici che non intervengono nel processo editoriale.
A questo si possono aggiungere stati e workflow: bozza, revisione, approvato, pubblicato o altri passaggi definiti dal progetto.
Il valore reale emerge quando un sito è gestito da più persone con responsabilità diverse. Se tutti hanno gli stessi permessi, una piattaforma molto granulare è superflua; se i processi editoriali sono complessi, diventa invece una caratteristica architetturale.
API e architetture headless o decoupled
Il Core è pensato anche per scenari nei quali il CMS gestisce dati e contenuti, mentre il front-end viene costruito con tecnologie differenti.
Comprende un modulo JSON:API strettamente collegato al sistema di entity e field. Questo permette di esporre i contenuti attraverso API e utilizzarli in un front-end JavaScript, un’app mobile, un servizio esterno o più canali contemporaneamente.
Se il concetto di interfaccia applicativa non ti è familiare, nella nostra guida spieghiamo cosa sono le API e come funzionano.
La possibilità tecnica, comunque, non significa che ogni progetto debba essere headless. Separare CMS e front-end aumenta libertà e indipendenza, ma introduce anche deployment, rendering, caching e debugging aggiuntivi.
Ha senso quando questi vantaggi risolvono un requisito reale, non perché “headless” suona più moderno.
A cosa serve Drupal e quali siti ha senso costruire
La piattaforma può adattarsi a molti tipi di progetto. La domanda più utile, però, non è quanti siti sia in grado di costruire, ma per quali progetti le sue caratteristiche giustificano la complessità introdotta.
Portali e siti con contenuti complessi
È un candidato forte quando il sito gestisce molte entità diverse e le relazioni fra loro sono parte essenziale del prodotto.
Un portale universitario può avere corsi, dipartimenti, docenti, sedi, eventi e documenti. Un sito istituzionale può gestire uffici, servizi, procedimenti, persone, comunicati e aree tematiche. Una piattaforma editoriale può collegare articoli, autori, dossier, argomenti e contenuti multimediali.
In questi casi non stai semplicemente pubblicando pagine: stai progettando un modello informativo.
La struttura dei dati diventa parte centrale dell’architettura invece di essere incorporata direttamente nelle singole pagine.
Organizzazioni con molti utenti, ruoli e processi editoriali
Quando la pubblicazione coinvolge decine di persone, un editor semplice può smettere di essere il problema principale.
Diventano più importanti domande come: chi può modificare cosa? Chi può pubblicare? Chi approva una determinata tipologia di contenuto? Un autore deve vedere anche le sezioni amministrative che non gli competono?
La granularità di ruoli, permessi e workflow rende questa soluzione adatta a organizzazioni nelle quali la governance editoriale è un requisito, non un dettaglio.
Progetti multilingua e multicanale
Il Core comprende strumenti per lingua dell’interfaccia, traduzione dei contenuti e traduzione della configurazione.
Questo non rende automaticamente semplice qualsiasi progetto internazionale: tradurre un sito significa anche definire processi, responsabilità, fallback, URL e governance delle varianti. Il vantaggio è avere un’infrastruttura pensata per gestire queste esigenze in modo strutturato.
Lo stesso modello dei contenuti può inoltre alimentare più destinazioni. Un’informazione inserita una volta può essere esposta sul sito principale, su una sezione dedicata o, attraverso API, su applicazioni esterne.
Integrazioni, applicazioni web e architetture headless
Un altro scenario naturale è quello in cui il CMS deve convivere con CRM, DAM, motori di ricerca interni, sistemi di autenticazione, database o servizi aziendali.
La natura API-first del Core rende questo tipo di integrazione coerente con l’architettura della piattaforma.
Non significa che ogni collegamento sia semplice. Più sistemi partecipano allo stesso progetto, più diventano importanti sicurezza, sincronizzazione, gestione degli errori e ownership dei dati. Gli strumenti disponibili consentono di costruire questa architettura; non eliminano il lavoro necessario per progettarla.
Quando Drupal è sovradimensionato
La flessibilità ha un costo.
Se devi creare un sito istituzionale di poche pagine, un blog personale o una presenza aziendale semplice gestita da una o due persone, potresti non avere bisogno di content model articolati, permessi granulari, workflow personalizzati e API.
In uno scenario del genere la domanda non è “può farlo?”. Certamente sì.
La domanda è: vale la pena sostenere una struttura tecnica più complessa per ottenere funzioni che probabilmente non userai?
Spesso la risposta è no.
Drupal CMS oggi: Canvas, site template, Recipes e AI
Drupal CMS nasce proprio per ridurre parte della distanza tra la potenza della piattaforma e l’esperienza necessaria per configurarla.
Non la trasforma però in un website builder completamente gestito. È più corretto considerarlo un punto di partenza più completo e più orientato alla costruzione visuale.
Drupal Canvas e l’editing visuale
Canvas porta la composizione delle pagine direttamente in un’esperienza visuale.
L’obiettivo è permettere a chi lavora sui contenuti di assemblare componenti, modificarli e verificare il risultato con meno passaggi fra form amministrativi e front-end.
Questa è una differenza importante per landing page e contenuti marketing, perché riduce la distanza tra modello strutturato e composizione visuale.
Non elimina però il content model sottostante. Anzi, il vantaggio maggiore arriva quando componenti visuali e struttura dei dati vengono progettati insieme, invece di usare il page builder per trasformare ogni pagina in un documento isolato.
Mercury e il sistema di componenti
Il prodotto include Mercury, una libreria di componenti utilizzabile con Canvas.
Hero, card, menu, testimonial, accordion e altri elementi comuni forniscono una base dalla quale partire senza progettare ogni componente da zero.
Per un sito professionale questo non significa necessariamente utilizzare per sempre i componenti predefiniti. Il valore sta soprattutto nel modello: un team può costruire un proprio design system e dare ai redattori blocchi controllati invece di lasciare totale libertà su HTML e presentazione.
È un compromesso interessante tra autonomia editoriale e coerenza visuale.
Site template e Recipes per ridurre il setup iniziale
I site template cercano di spostare il punto di partenza.
Invece di installare una base praticamente vuota e decidere immediatamente ogni modulo, content type e configurazione, puoi partire da un modello predisposto per un determinato scenario.
Le Recipes lavorano a un livello complementare: permettono di applicare configurazioni e funzionalità riutilizzabili.
Il vantaggio non è soltanto risparmiare qualche click. Rende più facile trasformare una soluzione già validata in un processo ripetibile, cosa particolarmente utile per agenzie e team che realizzano più progetti.
Cosa può fare l’AI e perché resta opzionale
Sono disponibili anche funzionalità AI opzionali.
Possono assistere nella generazione di contenuti o pagine, aiutare in attività amministrative e interagire con parti del processo di site building. L’utilizzo dipende però da configurazione, provider scelto e servizi disponibili.
È quindi sbagliato considerare “AI integrata” come sinonimo di sito che si costruisce automaticamente.
In un progetto serio restano necessarie decisioni su content model, permessi, componenti, dati, qualità editoriale e sicurezza. L’AI può ridurre lavoro ripetitivo o accelerare alcune operazioni; non sostituisce l’architettura del progetto.
Cosa Drupal CMS rende più semplice e cosa rimane tecnico
Canvas, componenti, template e Recipes riducono sensibilmente la frizione iniziale. Non cancellano però lo stack sottostante.
Aggiornamenti, dipendenze, hosting, Composer, moduli contrib, ambienti di sviluppo, deploy e integrazioni restano aspetti che richiedono competenze tecniche quando il progetto cresce.
Questo è probabilmente il modo più utile di leggere Drupal CMS: abbassa la soglia di ingresso su molte attività editoriali e di site building, ma non trasforma il sistema in un SaaS che nasconde completamente l’infrastruttura.
Vantaggi di Drupal: dove la piattaforma è realmente forte
Molte liste di vantaggi citano sicurezza, scalabilità e flessibilità come qualità astratte. Presi da soli sono termini poco utili.
Conviene capire quale meccanismo produce il vantaggio e in quali progetti conta davvero.
Contenuti strutturati e relazioni complesse
Il content model è probabilmente uno dei motivi più solidi per scegliere questa piattaforma.
Content type, field, entity reference, tassonomie e Views permettono di descrivere dati complessi senza ridurre ogni informazione a una singola pagina.
Il vantaggio cresce man mano che aumentano relazioni, filtri, visualizzazioni e canali di distribuzione.
Per un blog con titolo, testo e immagine è una capacità sovrabbondante. Per un catalogo editoriale con centinaia di attributi e relazioni può diventare il centro dell’intero progetto.
Governance, permessi e workflow
La granularità del sistema di accesso consente di separare con precisione responsabilità e attività.
Non è soltanto una questione di sicurezza. È anche un problema organizzativo.
Un buon workflow riduce il rischio che un redattore pubblichi accidentalmente qualcosa che richiede approvazione, che un collaboratore possa modificare aree non pertinenti o che ogni utente debba ricevere privilegi amministrativi troppo ampi.
Quando queste situazioni esistono realmente, il modello offre un vantaggio operativo concreto.
Multilingua e distribuzione dei contenuti
Il supporto multilingua è profondamente integrato nel Core attraverso moduli dedicati a lingua, interfaccia, contenuti e configurazione.
Questo permette di costruire una governance internazionale senza trattare ogni lingua come un sito completamente indipendente, anche se l’architettura finale dipende dal progetto.
Se gli stessi contenuti devono inoltre essere distribuiti su più front-end o servizi, l’approccio strutturato riduce la dipendenza dal formato visuale con cui vengono originariamente inseriti.
Estensibilità e integrazione con altri sistemi
Il sistema può essere esteso attraverso moduli, codice personalizzato e API.
Qui la parola “flessibilità” acquista un significato concreto: non sei limitato alle funzionalità predisposte da un servizio SaaS e puoi intervenire sul modello dei dati, sui processi e sulle integrazioni.
Naturalmente maggiore libertà significa anche maggiore responsabilità tecnica.
Se personalizzi profondamente una piattaforma, devi essere in grado di mantenere nel tempo ciò che hai costruito.
Open source e controllo della piattaforma
Il software è open source.
Questo significa che il codice può essere studiato, modificato e distribuito secondo la relativa licenza e che non sei legato al modello commerciale di un unico provider per utilizzare il CMS.
Non significa che il progetto sia gratuito.
Hosting, sviluppo, design, integrazioni, manutenzione, aggiornamenti e supporto hanno un costo. L’open source elimina il canone di licenza del Core; non elimina il costo del lavoro necessario per realizzare e governare una piattaforma professionale.
Limiti e svantaggi di Drupal
I punti di forza spiegano anche buona parte dei limiti.
Un sistema che consente di modellare contenuti, permessi e processi con grande precisione richiede più decisioni rispetto a una piattaforma che impone un percorso già definito.
Curva di apprendimento e competenze richieste
L’ecosistema ha una terminologia e un modello concettuale propri.
Entity, bundle, field, view, vocabulary, role, permission, configuration e recipe non sono concetti particolarmente difficili presi singolarmente. Il lavoro sta nel capire come combinarli per costruire un sistema mantenibile.
Drupal CMS rende più immediata una parte dell’esperienza visuale, ma progettare correttamente un sito complesso continua a richiedere competenze.
Per questo non valuterei la tecnologia partendo soltanto da quanto sia facile creare la prima pagina. Il test più utile è capire quanto sarà sostenibile amministrare e far evolvere il progetto tra due o tre anni.
Composer, sviluppo e manutenzione
Nel Core moderno Composer è una parte importante della gestione delle dipendenze e degli aggiornamenti. La documentazione corrente raccomanda infatti di gestire installazione e update attraverso Composer.
Questo ha vantaggi notevoli per riproducibilità e controllo delle versioni, ma alza il livello tecnico richiesto rispetto a un flusso interamente gestito da una dashboard.
Anche l’hosting va scelto tenendo conto di queste necessità. Prima di decidere l’infrastruttura conviene controllare i requisiti di sistema correnti invece di affidarsi a una vecchia lista di versioni PHP o database.
Costi reali oltre alla licenza gratuita
Il software può essere gratuito e il progetto costoso.
Un’implementazione complessa può richiedere analisi dell’architettura informativa, sviluppo custom, design system, migrazione dei contenuti, integrazioni, test, monitoring e manutenzione.
Non è un difetto specifico del CMS: è la conseguenza del tipo di progetti per cui viene spesso scelto.
Se la tua priorità assoluta è minimizzare tempo di sviluppo e competenze necessarie per un sito semplice, questa soluzione difficilmente parte favorita.
Perché la flessibilità può diventare complessità
Ogni scelta architetturale aggiunge anche qualcosa da mantenere.
Content type duplicati, moduli contrib inutili, ruoli poco chiari e configurazioni nate senza un modello coerente possono trasformare la flessibilità in debito tecnico.
La qualità del risultato dipende quindi molto dall’architettura iniziale.
Poter configurare quasi tutto non significa che sia utile configurare tutto.
Drupal e SEO: cosa permette di controllare davvero
La piattaforma può essere una buona base tecnica per la SEO, ma il CMS non garantisce alcun posizionamento.
La distinzione è importante perché formule come “SEO-friendly” spiegano molto poco.
URL, metadata, redirect, sitemap e contenuti strutturati
Il sistema permette di gestire alias degli URL e un modello di contenuti molto strutturato. Altre funzioni SEO vengono normalmente completate attraverso configurazione, Recipes o moduli dell’ecosistema.
Questo dà grande controllo, ma richiede che qualcuno definisca correttamente le regole.
Canonical, metadata, redirect, sitemap XML, dati strutturati e gestione dell’indicizzazione non diventano corretti semplicemente grazie al CMS scelto.
L’aspetto interessante è un altro: un content model ben progettato rende più facile applicare regole coerenti a intere famiglie di contenuti, invece di correggere manualmente pagina per pagina.
Drupal headless e implicazioni per rendering e indicizzazione
In un’architettura headless il CMS può occuparsi dei contenuti mentre il rendering viene affidato a un’applicazione separata.
Da quel momento la qualità SEO dipende anche dal front-end.
Status HTTP, canonical, metadata, link interni, rendering, sitemap, performance e gestione degli errori devono essere implementati correttamente nel livello che produce le pagine finali.
Quindi headless non significa automaticamente più veloce né più SEO-friendly. Offre maggiore libertà architetturale, ma sposta parte delle responsabilità dal CMS al front-end.
Perché usare Drupal non rende automaticamente un sito SEO-friendly
Due installazioni dello stesso CMS possono produrre risultati tecnici molto differenti.
Tema, infrastruttura, moduli, template, struttura dei contenuti, JavaScript, caching e competenze del team incidono sul risultato finale.
La piattaforma può facilitare un’implementazione solida. Non può sostituire una strategia SEO, una buona architettura informativa o contenuti adeguati all’intento di ricerca.
Lo stesso principio vale per WordPress, Joomla e gli altri CMS.
Drupal vs WordPress e Joomla: quando cambia davvero la scelta
Sono tutti sistemi open source, ma non ha senso cercare un vincitore assoluto.
Il confronto utile parte dal progetto.
Drupal o WordPress
WordPress tende a offrire un percorso iniziale più semplice e un ecosistema molto ampio per siti editoriali, aziendali, blog ed ecommerce.
La soluzione basata su Drupal diventa più interessante quando il requisito centrale non è semplicemente pubblicare pagine, ma modellare informazioni, governare numerosi ruoli, gestire workflow articolati o costruire integrazioni profonde.
Questo non significa che WordPress non possa affrontare progetti complessi o che l’altra piattaforma sia riservata a progetti enormi.
Significa che i due sistemi hanno punti di partenza architetturali differenti.
Se vuoi approfondire WordPress separatamente, puoi partire dalla nostra guida completa a WordPress.
Drupal o Joomla
Joomla occupa una posizione differente.
È un CMS generalista open source con gestione di contenuti, utenti, estensioni e funzionalità multilingua. Può offrire maggiore struttura di un semplice website builder senza adottare necessariamente lo stesso modello architetturale.
La scelta dipende ancora una volta dal problema dominante.
Quando content model, governance e integrazioni sono centrali, Drupal ha argomenti molto forti. Quando vuoi un CMS tradizionale più diretto e il progetto non richiede quella profondità, Joomla può essere una strada da valutare.
Per evitare di duplicare un intero intento di ricerca, abbiamo mantenuto il confronto completo nella guida dedicata a WordPress, Joomla e Drupal.
Matrice decisionale per scegliere il CMS
| Scenario | Drupal | WordPress | Joomla |
|---|---|---|---|
| Blog o sito aziendale semplice | Spesso sovradimensionato | In genere molto adatto | Possibile |
| Contenuti fortemente strutturati e relazionati | Molto adatto | Possibile con architettura adeguata | Possibile |
| Ruoli e workflow editoriali complessi | Punto di forza | Possibile, spesso con estensioni/configurazione | Buone capacità ACL |
| Integrazioni custom e API | Molto adatto | Ampio ecosistema e API disponibili | Possibile |
| Progetto headless/decoupled | Architettura naturale | Possibile | Possibile |
| Team non tecnico che vuole partire rapidamente | Drupal CMS riduce la complessità, ma resta uno stack tecnico | In genere più immediato | Intermedio |
| Controllo profondo del modello dei dati | Punto di forza | Possibile con sviluppo/plugin | Possibile |
| Ecosistema di temi/plugin pronti e accessibili | Ampio, ma più tecnico | Punto di forza | Più contenuto |
La tabella non assegna un vincitore perché la stessa caratteristica può essere un vantaggio in un progetto e un costo inutile in un altro.
Come iniziare con Drupal senza scegliere il percorso sbagliato
Il primo passo non dovrebbe essere installare moduli. Dovrebbe essere decidere quale livello della piattaforma serve davvero.
Quando partire da Drupal CMS
Drupal CMS ha senso quando vuoi rimanere nell’ecosistema ma preferisci un punto di partenza più completo.
Canvas, componenti, template e Recipes permettono di ridurre il lavoro di configurazione iniziale e danno a marketer e redattori un’esperienza più vicina al site building visuale.
Lo sceglierei soprattutto quando esiste comunque un team tecnico o un partner in grado di governare la piattaforma, ma vuoi evitare che ogni nuovo sito inizi da una base praticamente vuota.
Quando partire direttamente da Drupal Core
Partire dal Core ha più senso quando l’architettura è fortemente personalizzata e vuoi decidere con precisione quali componenti installare.
È il caso di piattaforme applicative, integrazioni profonde, workflow molto specifici o progetti nei quali il front-end è completamente separato.
Qui il vantaggio non è avere meno funzionalità: è evitare di introdurre un’opinione architetturale non necessaria prima di avere definito quella del progetto.
Come provare Drupal prima di adottarlo in produzione
Prima di scegliere un CMS sulla base di screenshot o demo, conviene costruire un piccolo proof of concept.
Definisci due o tre content type reali, crea le relazioni principali, configura almeno due ruoli con permessi differenti e prova il flusso editoriale che useresti davvero.
Se il progetto prevede API, testa anche una risorsa reale attraverso JSON:API.
La documentazione ufficiale Getting started raccoglie il percorso per installazione, ambiente locale e primi concetti.
Un test costruito sui requisiti del progetto vale molto più di una valutazione basata sulla quantità di funzioni presenti nella dashboard.
Domande frequenti su Drupal
Drupal è gratis?
Sì. Il Core è software open source e non richiede l’acquisto di una licenza per essere utilizzato.
Questo non rende gratuito il sito. Hosting, progettazione, sviluppo, design, manutenzione e integrazioni hanno costi che dipendono dal progetto.
Drupal è difficile da usare?
Dipende da cosa devi fare.
Per un redattore che lavora in un’interfaccia già progettata correttamente, pubblicare contenuti può essere semplice. Per chi deve progettare da zero content model, moduli, workflow, deployment e integrazioni, la curva di apprendimento è più alta.
Drupal CMS riduce parte della difficoltà iniziale attraverso Canvas, componenti e configurazioni predefinite, ma non elimina la natura tecnica della piattaforma.
Drupal è sicuro?
Esiste un Security Team dedicato e vengono pubblicati security advisory ufficiali per il Core e i progetti contrib coperti.
Questo è un processo di sicurezza strutturato, non una garanzia di invulnerabilità.
Un sito non aggiornato, configurato male o dipendente da codice non supportato può comunque essere vulnerabile. La sicurezza dipende anche da aggiornamenti, hosting, permessi, moduli utilizzati e procedure operative.
Drupal CMS sostituisce Drupal Core?
No.
Drupal CMS è costruito sul Core. Quest’ultimo continua a essere la base del sistema e il punto di partenza appropriato per progetti che richiedono maggiore controllo sull’architettura.
La differenza riguarda il livello di configurazione fornito all’inizio, non l’esistenza di due piattaforme incompatibili.
Drupal serve solo per siti enterprise?
No.
Può essere usato anche per progetti più piccoli. Il punto è capire se le sue caratteristiche producono abbastanza valore da giustificarne la complessità.
Se devi gestire contenuti strutturati, relazioni, workflow, multilingua o integrazioni, può avere senso anche senza essere una multinazionale.
Se devi pubblicare un sito semplice con poche pagine e un solo redattore, probabilmente esistono soluzioni più proporzionate.
Conclusione
Drupal è una scelta particolarmente forte quando il problema da risolvere riguarda struttura dei contenuti, governance, permessi, workflow, multilingua o integrazioni, non soltanto la costruzione delle pagine.
Drupal CMS rende l’ingresso più accessibile grazie a Canvas, componenti, template e Recipes. Il Core continua invece a offrire la base più libera per architetture costruite su misura.
Lo sceglierei quando sai spiegare quale requisito concreto richiede quella flessibilità. Se il progetto è semplice e il principale obiettivo è pubblicare rapidamente con il minor carico tecnico possibile, adottare una piattaforma tanto configurabile rischia di complicare inutilmente il lavoro.
Il criterio giusto, quindi, non è chiedersi se sia “migliore” di WordPress o Joomla. È capire se il tuo progetto ha davvero bisogno del tipo di controllo che mette a disposizione.