Un glossario ragionato della terminologia Drupal

Credo che ormai tutti abbiano sentito parlare di Drupal, un CMS che sta
giorno per giorno guadagnando consensi, tanto da divenire quasi la scelta
obbligata (perlomeno come sistema da considerare o confrontare) ogni qualvolta
si cerchi un sistema per la gestione dei contenuti.

I motivi di questo successo sono, a mio parere, i seguenti:

  • enorme (e crescente) base di installato (community di utilizzatori)
  • grande e reattiva community di sviluppatori
  • rilasci frequenti (feature e bug fix)
  • architettura estremamente modulare (un plus per chi ci sviluppa)
  • grande quantità di moduli per qualsiasi esigenza (un plus per chi lo utilizza)

Tuttavia esistono anche dei problemi; alcuni sono a livello
di programmazione del CMS (dove per questo Drupal è meglio definito come un
CMF – F per Framework), che qui non ci interessano, mentre
il problema che questo articolo vorrebbe tentare di alleviare un po’ è
quello della terminologia. Una volta deciso che Drupal fa al caso
nostro, occorre infatti impratichirsi con una serie di termini dal significato
non immediato della “galassia Drupal”.

Questo articolo si rivolge in primis a coloro che hanno provato o stanno
provando Drupal e cerca di semplificargli un po’ la vita; le prime volte che
ho installato Drupal, infatti, ricordo che le maggiori difficoltà le incontravo nel capire
bene cosa avevo davanti e come mettere insieme i vari pezzi.

Chi invece non ha mai provato Drupal ma conosce altri CMS, può forse farsi
mentalmente un’idea delle differenze tra questo CMS ed altri che conosce.
Nella descrizione dei termini cercherò di entrare sufficientemente
nei dettagli cercando di mostrare, per quanto possibile, le loro potenzialità.

Il nodo

Il primo oggetto che analizziamo è il nodo, sicuramente il concetto
più importante e generico di Drupal. Un nodo è semplicemente sinonimo di
“contenuto”; praticamente, esistono eccezioni, qualsiasi contenuto gestito da
Drupal è un oggetto di tipo nodo. Ogni nodo ha delle proprietà di base: il
titolo, il contenuto, l’autore, la data di creazione ecc.; tramite
appositi meccanismi è poi possibilie aggiungere altre proprietà, oltre a
quelle presenti per default.

Caratteristica importante di ogni nodo è che questo ha un tipo. Anche
qui niente di particolarmente esotico, esistono tipi “blog”, “story”, “page”,
“image”, ecc. Ancora una volta, tramite particolari meccanismi è
possibile aggiungere tipologie di nodi alla nostra installazione di Drupal.

Di default, appena installato, Drupal arriva configurato con i nodi di tipo
“story” e “page”, che solitamente sono utilizzati rispettivamente per le
pagine di tipo “notizia” e “pagina statica” (come le classiche ‘chi siamo’ e
‘about’).

Il modulo

Drupal non è certo famoso per essere un sistema che una volta installato è
subito pronto a servire qualsiasi esigenza; una volta installato offre già
delle buone funzionalità di base, certo, ma la caratteristica
dove invece eccelle è la sua possibilità di essere esteso.

Il principale meccanismo che permette di aggiungere funzionalità al nostro
sito Drupal è il modulo. In
altri sistemi lo stesso concetto è implementato tramite i plug in.

Ogni modulo consiste di uno o più file PHP che, una volta installati,
modificano il comportamento di default di Drupal o aggiungono nuovi tipi
di nodo, nuove funzionalità o modificano i nodi già presenti. Per come
Drupal è stato pensato dall’inizio, non esiste praticamente niente che
un modulo aggiuntivo non possa fare.

Ci sono tre tipologie di moduli in Drupal: i moduli
core e non removibili, come dice il nome,
arrivano direttamente dalla distribuzione di Drupal, sono attivi per default e
non possono essere disabilitati. Poi ci sono quelli core e
rimovibili
, un set di moduli che arriva direttamente
insieme alla distribuzione principale ma possono essere a scelta attivati o
disattivati. Infine, la tipologia più interessante, la categoria
terze parti ovvero i moduli non presenti nella distribuzione
principale, scaricabili direttamente dal sito Drupal, il quale
mantiene un repository sempre aggiornato degli stessi.

Questi moduli, forniti dalla comunità, sono creabili da chiunque, non certo solo
dagli sviluppatori del team di Drupal… Questo è sia un bene che un male: da una
parte la quantità di moduli è semplicemente impressionante; dall’altra spesso
va un po’ a scapito della qualità essendoci moduli che rimangono per sempre in
stato “sperimentale”, moduli che semplicemente… non funzionano, altri che non
supportano la versione di Drupal installata e moduli che condividono totalmente o
parzialmente delle funzionalità con altri.

Il difficile di Drupal sta tutto qui: quali moduli
devo usare per implementare le funzionalità che voglio offrire e che magari non
ho ancora neanche troppo chiare? Esiste davvero un modulo per qualsiasi
problema o finirò con il dovermi scrivere qualcosa io?

Articoli come questo si fissano l’obiettivo di aiutare un po’ in questo
difficile compito… Ovviamente non c’è niente che possa sostituire
l’esperienza dello sviluppo di altri siti con questo CMS.

Vista la sua potenza, il sistema dei moduli è anche quello che nel tempo, tra
un rilascio ed un altro, viene più spesso modificato: si aggiungono
funzionalità si modifica (migliorandolo) il relativo sistema di installazione
e disinstallazione, si rifattorizza il layout delle directory, ecc.

Come effetto collaterale di queste continue modifiche alla gestione dei
moduli, si ha che spesso tra una major release all’altra (per esempio dalla
corrente versione 5 alla prossima 6) i moduli smettano di funzionare (non
tutti, per fortuna!). Gli sviluppatori sono dunque chiamati a
effettuare le necessarie modifiche al fine di garantire la compatibilità con
la nuova versione. Fortunatamente questo succede regolarmente: il tasso di
“mortalità” dei moduli più interessanti è bassissimo.

La regione

Con la regione entriamo nel campo relativo a come i contenuti vengono
visualizzati.

Drupal definisce una serie di regioni in cui è suddiviso il
layout delle pagine.

Le regioni di default sono:

  • Barra laterale destra
  • Barra laterale sinistra
  • Contenuto
  • Intestazione
  • Messaggio a pié di pagina

La loro posizione direi che è abbastanza autoesplicativa.

È tuttavia possibile creare altre regioni in modo da avere un
controllo ancora più fine su come i contenuti appaiono nei nostri template.

Le regioni sono dunque zone all’interno delle quali Drupal permette di
inserire un particolare tipo di contenuto: il blocco.

Il blocco

Il blocco in Drupal non è altro che un pezzetto di codice HTML che verrà
visualizzato all’interno della regione alla quale verrà collegato (tale
operazione viene solitamente effettuata dagli amministratori).

Questo codice HTML può essere immaginato, nella sua forma più semplice,
come un elemento H (il titolo del blocco) seguito da un generico DIV
all’interno del quale verrà inserito il contenuto vero e proprio (qualsiasi
cosa: liste, immagini, paragrafi, testo, ecc.).

Esistono fondamentalmente due fonti di blocchi: una sono i moduli, i quali
infatti possono esporre dei blocchi di contenuto: pensate per esempio al
blocco contenente la form per il login, con username e password; ecco, questo
è per l’appunto un blocco esposto dal modulo user. Ogni modulo può
esporre quanti blocchi vuole; l’amministratore troverà tutti questi blocchi
nella sezione relativa dell’amministrazione del sito; dovrà solo scegliere se
attivarli e, nel caso, in quale regione metterli.

L’altro sistema di creare blocchi è farlo a mano: l’amministratore (o comunque
chi ne ha facoltà), ha la possibilità di creare dei blocchi di HTML “statico”,
dargli un nome e poi ancora una volta attivarli scegliendo la regione. In
realtà questa possibilità, volendo, va ben aldilà dell’HTML statico: è
infatti possibile inserire all’interno dei blocchi anche del codice PHP ed
aver accesso alle variabili globali esposte da Drupal nei propri template.
Esistono, nei documenti creati dalla comunità sul sito di Drupal, decine di snippet di codice
PHP per aggiungere simpatiche funzionalità semplicemente incollandone il
contenuto all’interno di uno di questi blocchi “manuali”.

Anche la visualizzazione dei blocchi può essere personalizzata: è possibile
infatti decidere che un certo blocco appaia soltanto su certe pagine, per
esempio solo in home page, oppure al contrario non appaia su altre.

Per ogni pagina che viene visualizzata, esiste una sola istanza di un blocco e
dunque questo può “vivere” all’interno di una sola regione. Non è possibile
stabilire, per esempio, che lo stesso blocco sia presente sia nella regione
Intestazione che nella regione Contenuto.

Il ruolo

Il concetto di “ruolo utente” in Drupal è lo stesso condiviso da tanti altri
sistemi: è possibile infatti inserire gli utenti all’interno di gruppi (ruoli,
appunto). Ad ogni gruppo vengono conferiti particolari diritti relativi a
quello che possono fare gli utenti al loro interno. Questi diritti sono
anch’essi esposti dai singoli moduli. Appena un nuovo modulo viene attivato
sarà compito degli amministratori andare a verificare che questo abbia
aggiunto dei particolari diritti e, nel caso, abilitarli (o meno) sui ruoli
definiti nel sito.

A proposito dei ruoli, è bene sapere che:

  • Esiste un unico utente veramente onnipotente, in Drupal (che è il primo
    utente creato). Non esiste, tuttavia, un gruppo onnipotente. Se serve, è
    possibile definire un ruolo “amministratore” all’interno del quale saranno
    attivati tutti i possibili diritti. Comunque non si arriverebbe al totale
    controllo che si ha lavorando da “utente 1”.
  • Un Drupal fresco di installazione avrà predefiniti i ruoli utente
    registrato
    e utente anonimo. Questi ruoli sono anche
    built-in e come tali non possono essere rimossi.
  • Un utente può essere inserito in più gruppi. Un utente che effettua il
    login andrà sempre a finire nel ruolo utente registrato, ma
    potrebbe anche essere un Pubblicatore (nome di ruolo che mi
    sono appena inventato). Questo vuol dire che non è necessario copiare tutti
    i diritti di utente registrato per il ruolo
    Pubblicatore. Tali diritti infatti saranno automaticamente
    ereditati.

CCK

Fino a qualche tempo fa uno dei punti deboli di Drupal era che estenderlo con
nuovi tipi di documento, voleva dire, troppo spesso, rimboccarsi le maniche e
iniziare a scrivere codice PHP e SQL. Per ovviare al problema vide la luce il
modulo flexinode, che
permetteva anche ai non programmatori di creare, tramite interfaccia di
amministrazione del sito, nuovi tipi di documento (una press release, per
esempio).

Successivamente, sempre per lo stesso scopo, vide la luce un altro modulo
assai più potente: il CCK (Content
Construction Kit)
.

I due moduli sono molto diversi nell’approccio: il primo crea proprio dei tipi
di documento nuovi, il CCK invece permette di creare dei campi
contenuto
raggruppando i quali è poi possibile creare nuove tipologie di
documento. La cosa interessante è che questi campi nuovi possono essere anche
usati per estendere tipi di nodo già esistenti: è possibile, per
esempio, aggiungere il campo Fonte, come URL da specificare
quando si inserisce un documento di tipo story, che di default
non ha quel campo.

CCK ha, esso stesso, un’architettura modulare: nel repository ufficiale di
Drupal, sono disponibili ben 94 moduli aggiuntivi
che si basano su CCK per fornire altre funzionalità e nuovi tipi di dato per
Drupal.

Inutile dire che CCK ha ormai completamente reso obsoleto il vecchio flexinode.

Nelle prossime versioni di Drupal il CCK farà parte del suo “core” e non sarà
necessario neanche installarlo.

La view

Tramite una view è possibile creare una visualizzazione personalizzata di una
lista di documenti. In pratica si tratta di un potente query builder
ad uso dei non programmatori. Anche le view vengono fornite da un apposito modulo.

Traducendo la lista degli esempi dalla pagina del progetto:

  • Ti piace come viene visualizzata la home page (è una lista di nodi), ma la vuoi
    ordinata in maniera diversa
  • Usi il tracker (lista degli ultimi documenti inseriti) ma vuoi che vengano elencati soltanto
    i documenti di un certo tipo
  • Ti serve un sistema per visualizzare un blocco con gli ultimi 5 documenti di un certo tipo
  • Ti serve un sistema per visualizzare gli ultimi 5 post non letti del forum
  • Ecc., ecc.
  • Il profilo utente

    Quando un utente si registra, i dati che vengono richiesti sono soltanto quelli
    strettamente indispensabili: username, email e password. Ma come fare se un sito
    ha bisogno di raccogliere più dati per la profilazione dell’utente (anche soltanto
    il Nome e Cognome, per esempio, o il Comune di residenza)?

    Questo è appunto il compito dei “profili utente”, funzionalità offerta dal modulo Profile (è un
    modulo “core” e non occorre installarlo).

    Il modulo, oltre a permettere di aggiungere, come il CCK, dei campi
    addizionali al profilo di un utente, aggiunge anche la possibilità di
    effettuare ricerche avanzate su questi (per esempio: ricerca tutti gli
    utenti residenti a Bologna).

    La tassonomia

    Anche questo è un concetto fondamentale in Drupal: tramite le tassonomie è
    possibile categorizzare i contenuti. Non a caso la traduzione italiana per
    questa funzionalità (taxonomy, in inglese) è proprio “categorie”
    (personalmente ritengo comunque che quella sia una traduzione sbagliata o
    quantomeno fuorviante).

    Il meccanismo è piuttosto semplice, ma su di esso si fondano poi funzionalità
    (tramite dei moduli
    aggiungivi
    ) complesse e potentissime.

    Il sistema tassonomico di Drupal si basa su due concetti: i
    vocabolari e i termini ad essi associati. Un
    esempio chiarirà subito il loro significato.

    Immaginate di aver un sito sul quale gli utenti creano dei documenti di tipo
    “immagine”. Tramite la tassonomia voglio poter catalogare queste immagini in
    base al loro soggetto principale. Per questo scopo potrei creare un
    vocabolario che si chiama “Soggetti immagine” e poi inserire al suo interno
    termini come “Ritratti, Animali, Paesaggi, Natura, Varie”. Associerò poi quel
    vocabolario ai nodi del tipo “immagine”. Da quel momento, tutte le volte che
    un utente caricherà un’immagine, gli sarà richiesto di selezionare il soggetto
    scegliendolo da una lista predefinita di termini (che sono appunto quelli che
    sono stati inseriti nel vocabolario).

    Quando si definisce un vocabolario è anche possibile dichiarare che tale dato
    è obbligatorio o a scelta multipla, oppure che il vocabolario è di tipo “ad
    albero” – in modo da creare una gerarchia dei termini, o anche che quel
    vocabolario accetta termini in modo free tagging attivando in pratica un
    sistema di categoriazzazione a tag con tanto di autocompletamento ajax.

    Una volta che un sito ha definita la propria tassonomia, si avrà
    automaticamente accesso a tutta una serie di funzionalità, come ad esempio la
    lista di tutte le immagini che hanno “Animali” come soggetto (compreso RSS),
    oppure un menu creato in base ad un particolare
    vocabolario
    , oppure tramite un modulo aggiuntivo, ecco pronta una tag cloud.

    Concludendo

    I termini che ho qui presentato possono anche essere ritenuti i
    concetti chiave di Drupal ma tuttavia questo non è e non
    voleva essere un elenco di tutte le funzionalità del CMS. Probabilmente tale
    elenco potrebbe essere lo scopo di un altro articolo, da collegare magari
    all’uscita prossima della versione 6 che nel momento in cui scrivo si trova in
    fase di Release candidate 1,
    alla quale seguiranno probabilmente altri due rilasci “RC”, prima della
    versione definitiva.

    Drupal non sarà forse il miglior CMS in
    circolazione, ma se ha vinto il premio come miglior
    CMS Open Source del 2007
    un motivo ci sarà, e anche più di uno, direi. Da
    qui il mio consiglio: provatelo e magari usate questo articoletto per
    orientarvi tra i suoi concetti chiave.

    Comments

    1. Giacomo says:

      Errore di digitazione:

      riga 6: enorme (e crescente) base di installato???? (community di utilizzatori)

    2. Avevo provato Drupal tempo fa e confermo che effettivamente i vari termini mi avevano spiazzato… E’ stato utilissimo questo tuo articolo! 🙂

      Ciò che però non mi piace di Drupal è il sistema di template… Trovo fantastico Smarty e quindi vedere php misto ad (x)html non mi piace affatto…
      (C’è qualche modulo, non abbandonato, x permettere l’utilizzo di Smarty o template engine simili?)

      So che Drupal è comunque un ottimo CMS, ma mi domando se iniziando oggi un nuovo progetto sia più conveniente affidarsi ad un CMS (come Drupal) o ad un framework (come CakePHP)…
      E non penso dipenda solo dal tipo di progetto…

    3. Perché errore di digitazione? Si dice sia base di installato che base installata. Ma il primo modo e` più giusto, secondo me, perché è l’abbreviazione di “base di software installato”.

    4. claudio says:

      @epper, ebbene sì, anche il template engine di Drupal è modificabile. Di default viene utilizzato appunto “phptemplate” dove, come dici tu, si utilizza direttamente del PHP in HTML.

      Se vuoi usare Smarty, eccolo qua: http://drupal.org/project/smarty

    5. Enrico Camero says:

      Ottimo articolo!
      Qualcuno saprebbe consigliarmi un libro (anche in lingua inglese) per comprendere meglio come sfruttarne meglio tutte le caratteristiche? Per uno abituato ai classici CMS tipo Joomla non è molto immediato l’uso di Drupal 🙂

    6. Per Enrico: io ti consiglio Pro Drupal Development della APRESS. Lo trovo ottimo e lo consulto molto spesso per i miei lavori. Io l’ho comprato da Amazon.fr perchè con le spedizioni costava molto meno che da Hoepli.

    7. @enrico
      Io ho letto Pro Drupal Development di Apress, sono partito da zero e (grazie anche al libro) ho tirato fuori un mini-ticket-manager in una settimana. Resto comunque cauto nel giudizio sui cms usati come frameworks!

    8. Tobe Bofh says:

      @Enrico:
      Io mi sono trovato bene con i volumi di Packt Publishing (che puoi anche acquistare solo in PDF):
      http://www.packtpub.com/drupal-books

    9. Ottimo articolo..una bella infarinatura ci voleva; lo provero’ nei prossimi giorni.

    10. Enrico Camero says:

      @ZioBudda
      @Masci
      @Tobe Bogh
      Grazie mille a tutti…andrò a fare un giretto su Amazon allora! 😉

    11. Walter Franzini says:

      Sarei interessato ad approfondire la questione dei problemi di programmazione del CMS.

      Esistono indicazioni da qualche parte?

    12. claudio says:

      @walter, a mio parere i problemi sono principalmente due: uno è dovuto al fatto che se impari a programmare moduli Drupal per la versione 4.7, quando passerai alla 5.0 hai da buttare il 20% dei quello che sai e devi imparare un altro buon 20%… questo perché gli sviluppatori di Drupal hanno sempre scelto una strada un po’ radicale sulla questione “refactoring” 🙂 Il che non è un male (embrace the change!), ma può essere faticoso e un po’ frustrante…

      L’altro problema è l’approccio misto oggetti/non-oggetti del core di Drupal… alcune cose sono oggetti, altre no… il concetto di ereditarietà è una STI… cose così…

      Un altro problemino (legato al precedente) è quello legato alla quantità di variabili globali presenti e anche un po’ sconosciute (vedi http://drupal.org/node/198569 )

      Niente di impressionante, ma sicuramente cose che fanno un po’ storcere il naso.

    13. Drupal è il pezzo di software più power angry che abbia mai visto sul web.

      Scappate prima di riempire il web di siti web con centinaia di query MYSQL per ogni pagina che genera.

    14. claudio says:

      @lorenzo: sono abbastanza d’accordo. Su un sito parecchio trafficato abbiamo dovuto penare un po’… ma sai com’è… fine tune della cache di MySQL… modulo Boost… modulo block cache… la stessa cache di Drupal… memcache… insomma i sistemi si trovano 🙂

    15. Molto interessante.
      Ho utilizzato Drupal per progetti lavorativi alcune volte in passato ma mi sono sempre un po’ scontrato con questo suo essere più “framework” che “solution”. Irrimediabilmente si riescono a coprire l’80% delle feature in un tempo irrisorio, semplicemente assemblando i moduli (fantastico), e poi si investe il resto del tempo di progetto (quando va bene) per “piegare” Drupal per fare le cose esattamente come le vuole il committente (per non parlare della creazione del tema 😛 ).
      Ops, scusate la digressione, il punto era che è opportuno saper identificare lo strumento giusto per ogni occasione; Drupal è fenomenale per risolvere la sua classe di problemi.

    16. @claudio: sono d’accordo con Lorenzo: se un pezzo di software richiede necessariamente tutto quel lavorio accessorio solo per funzionare come dovrebbe allora è un pezzo di software fondamentalmente inutile.

    Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.