Lo scopo di questo articolo non è quello di fornire un tutorial (se si ha bisogno di tali informazioni in rete è possibile trovarne a dozzine anche nel canale Youtube) bensí dare un’idea di massima sulle potenzialità di alcuni strumenti chiave di Drupal 7.

Una delle maggiori novità di quest’ultimo, ufficialmente rilasciato nel Gennaio 2011 dal belga Dries Buytaert, consiste nell’introduzione del nuovo paradigma Entity e relative API.
Un’Entity in Drupal è un’istanza di quella che può essere definita una classe Base chiamata Entity Type che, a sua volta, può essere qualsiasi tipo di contenuto, come ad esempio:

• Vocabolari di Tassonomie
• Utenti
• Nodi
• Commenti di utenti

I concetti legati a questo paradigma sono sostanzialmente quattro:

• Entity Type – una classe base che offre un livello di astrazione tale per cui a quest’ultima è possibile associare Fields customizzati
• Bundle – una classe Extended della classe Base Entity Type, per cui è possibile creare due o più Bundles che si riferiscono alla medesima Entity Type
• Field – un pezzo di codice riutilizzabile, vale a dire un metodo o una proprietà o anche un field-instance di una classe Bundle o di una classe Entity Type
• Entity – un oggetto di una classe Entity Type o di una classe Bundle.

Grazie alle Entities è stato possibile sviluppare uno dei moduli più utili e attualmente disponibili nel progetto Drupal, soprattutto quando si lavora in un contesto Multisite: Drupal Features.

Drupal Features è un modulo Contributed o Contrib (vale a dire quei moduli sviluppati dalla Comunità in base a regole prestabilite e caricati in appositi Repositories GitHub) sviluppato dallo statunitense Mike Potter e attivamente mantenuto e aggiornato da altri sviluppatori e software architects.

Sfortunatamente questo modulo non è documentato granché nelle più note guide stampate, anche se meriterebbe un approfondimento assai maggiore data la sua indiscutibile utilità in progetti ‘modulari’, vale a dire quei progetti che presentano molto spesso caratteristiche funzionali identiche e ripetitive.

Per portare un esempio pratico di quali siano le potenzialità di questo modulo, basti immaginare di dover gestire dieci siti per ciascuno dei quali siano richiesti il medesimo modulo contatti e la medesima area News o Events.
Chi è pratico di Drupal sa che per creare un’area News ad esempio è necessario creare un Content Type con i relativi Fields e relative Views.
Anziché ripetere per dieci volte la medesima procedura è sufficiente creare una Feature e abilitarla su ciascun sito laddove sia necessaria con un semplice comando Drush.
Allo stesso modo è possibile applicare modifiche strutturali aggiornando semplicemente la feature ed eseguendo un comando ‘Revert’ atto ad aggiornarne i parametri secondo una logica che ricorda vagamente quella del noto Pattern Observer.

Quindi, fondamentalmente una feature è un pacchetto preconfezionato di configurazioni, atto a creare dei componenti ‘ready to use’ nei quali è possibile collezionare qualsiasi tipo di informazione in termini di mera configurazione, non solo a livello System ma anche a livello di Dependecies (anche grazie al Modulo Strongarm utile nell’esportazione di variabili di sistema).

Cosa sono le Dependencies? Chi sviluppa moduli Drupal già lo sa. Una Dependency può essere o un Modulo o un’altra Feature contenente un set di parametri necessari a quelli contenuti nella Feature che la richiede: la Child Feature.
Per fare un altro esempio pratico, s’immagini una Core Feature che definisce un nuovo utente “Web Master” con specifici ruoli e permessi e una Feature News dove l’utente Web Master ha la possibilità di impostare il Display Mode e la posizione del Blocco Vista nelle singole Regioni della pagina.
Ovviamente il medesimo ruolo potrebbe essere richiesto anche da altre Features
come ad esempio una Feature per la gestione degli Eventi o un’altra per la gestione di Pubblicazioni o magari di una Video Gallery.
Ecco che a questo punto risulta piuttosto chiara l’utilità di collezionare le configurazioni di base comuni a tutte le features in una Core Feature opportunamente definita nella dependency list di tutte le altre.

Ora, a fronte di ciò, proviamo ad espandere un altro po’ il campo visivo e immaginare simili potenzialità in un contesto Multisite opportunamente configurato dove i dieci siti di cui parlavamo poco fa, facciano capo al medesimo Drupal Core (come da Best Practice quando si gestiscono progetti multipli Drupal Based) e con essi anche le singole Features.
Anziché aggiornare l’area News (alla quale magari è necessario aggiungere un campo o modificare dei permessi) su ‘n’ siti uno per uno, è sufficiente applicare le modifiche alla singola Feature che contiene i vari parametri di configurazione ed eseguire una Revert per ogni progetto (visto che le modifiche hanno effetto a livello di database) mantenendo però quel livello di uniformità fondamentale per coloro che devono gestire progetti multipli più o meno complessi che siano.

Il modulo Features fornisce un Pannello di generazione per cui chiunque può generare una feature selezionando o meno gli elementi che deve collezionare nel set di configurazione ma questa procedura tende a generare codice ‘spazzatura’, che non è dannoso in termini funzionali, ma sporca abbondantemente i sorgenti.
Gli sviluppatori back-end solitamente odiano questo processo per ovvie ragioni e, quando acquisiscono un certo grado d’esperienza, normalmente provvedono ad una pulizia manuale dei sorgenti. Inutile dire che i presupposti essenziali per un codice mantenibile sono pulizia/leggibilità e sinteticità.

In conclusione, se siete in procinto di avviare una serie di nuovi progetti utilizzando il FMS (Framework Management System) Drupal 7, l’approccio Multisite e l’utlizzo del modulo Features sono assolutamente fondamentali.