Un glossario ragionato della terminologia Drupal di Claudio Cicali

Programmazione 16 commenti Un glossario ragionato della terminologia Drupal di Claudio Cicali

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 modulo


• La regione


• Il blocco


• Il ruolo


• CCK


• La view


• Il profilo utente


• La tassonomia

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.

Pubblicato il 8 Gen 2008

Trackback Trackback link

Tag

cms drupal php