IMPORT/EXPORT IN SISTEMI CMS

Transcript

1 POLITECNICO DI MILANO Polo Regionale di Como Facoltà di Ingegneria dell'informazione Corso di Studi in Ingegneria Informatica IMPORT/EXPORT IN SISTEMI CMS RELATORE: Marco Brambilla ELABORATO FINALE DI: Manfredi Andrea Matricola: ANNO ACCADEMICO 2009/2010 1

2 Indice 1 Introduzione CMS ( Content Management System ) Un problema fondamentale: L'integrazione Obbiettivi della Tesi Struttura Tesi I Sistemi CMS I CMS Cenni Storici Vantaggi e svantaggi dei CMS Gestione dei contenuti I Web Content Management System Problemi di Integrazione Cms to Web Service Web Service to CMS I più usati e famosi CMS Joomla! Caratteristiche Estensioni Componenti Moduli Template Mambot Drupal Storia Struttura I Moduli Contenuti Viste Import/Export in Drupal Backup and Migrate Printer, and PDF versions User Import Taxonomy import/export via XML Taxonomy CSV import/export Views Datasource Custom Reports Views Importer Save To FTP Node Table CCK Importer Views Node Feed Joomla To Drupal

3 4 Prove con il portale Energy CH-IT Cos'è l'energy CH-IT Moduli per l'import di database in Drupal Modulo Sheetnode Node Import Creazione di un nuovo content type tramite il modulo CCK Modulo Node Import, utilizzo pratico Passo 1: Selezione del Content Type Passo 2: Selezione del le da importare Passo 3: Impostazioni del le da importare Passo 4: Mappatura degli attributi del le con i campi della struttura dati Passo 5: Opzioni per l'importazione Passo 6: Impostazione dei valori di default Passo 7: Anteprima dei dati Passo 8: Inizio dell'import Creazione di interrogazioni sul database tramite le Viste Problemi riscontrati con l'operazione di migrazione del database 54 5 Conclusioni 59 A Glossario 60 3

4 1 Introduzione 1.1 CMS ( Content Management System ) Un Content Management System (CMS), che tradotto signica sistema di gestione dei contenuti, è uno strumento software installato su un web server progettato per pubblicare e gestire contenuti sul web. Solo questa parte di denizione non indica nulla di particolare che già non si possa fare. Per questo, per comprendere meglio lo scopo dei CMS è necessario introdurre un ulteriore pezzo di denizione: La pubblicazione e la gestione dei contenuti è permessa anche per coloro che non conoscono le tecniche di programmazione web. Esistono numerosi CMS, essi vengono suddivisi in due principali categorie: CMS specializzati ( forum, blog, siti vetrina, enciclopedie on-line, ecc.) CMS generici, che sono per natura più essibili, e possono essere congurati per la gestione di vari tipi di contenuti Si può facilmente intuire che quelli specializzati derivino da quelli generici; la distinzione viene fatta semplicemente per far emergere il lavoro già svolto ( con- gurare CMS generici per creare CMS specializzati) e per favorire il riuso di questi modelli già costruiti evitando le perdite di tempo. Tecnicamente un CMS è un'applicazione lato server che si appoggia su un database preesistente per lo stoccaggio dei contenuti ed è suddivisa in due parti: la sezione di amministrazione (back end), che serve ad organizzare e supervisionare la produzione dei contenuti, e la sezione applicativa (front end), usata dall'utente per la fruizione dei contenuti e delle applicazioni del sito. L'amministratore del CMS gestisce dal proprio terminale, tramite un pannello di interfaccia e controllo, i contenuti da inserire o modicare e invia i dati al database del server tramite protocollo FTP. 1.2 Un problema fondamentale: L'integrazione L'integrazione di Web Service in un CMS è un aspetto fondamentale per comprendere le potenzialità di un Content Management System. Approcciarsi ad un nuovo metodo per sviluppare il proprio sito web senza questa possibilità sarebbe inutile poiché si andrebbe a perdere un eventuale lavoro già svolto in passato. Per questo motivo gli sviluppatori aggregati ai vari CMS hanno speso molto tempo per riuscire ad ottenere un set di strumenti (i moduli) che fosse in grado di coprire quasi totalmente l'aspetto della migrazione da un sito web sviluppato con le comuni tecniche di programmazione web ad uno sviluppato tramite CMS. I moduli che sono tutt'ora disponibili hanno molte potenzialità ma non devono essere sottovalutati poiché il loro utilizzo necessità un certo di livello di accortezza. Per questo motivo il problema dell'integrazione verrà trattato più dettagliatamente nella sezione successiva. 4

5 1.3 Obbiettivi della Tesi Gli obbiettivi di questa tesi sono molteplici: 1. Comprendere in modo dettagliato i problemi dell'integrazione tra web service e CMS; 2. Approfondire l'argomento dell'import/export, per comprendere le potenzialità di queste piattaforme nell'interfacciarsi con il resto degli attori presenti sul web; 3. Identicare un set di strumenti (moduli) adatti alla risoluzione delle varie casistiche di import/export; 4. Applicare i concetti appresi su un caso d'uso reale, il portale ENERGY- CHIT. 1.4 Struttura Tesi La tesi, oltre alla parte di introduzione, contiene: Una sezione di approfondimento sui concetti base dei sistemi CMS ( I Sistemi CMS ). La sezione principale in cui vengono descritti i Moduli Utilizzati ( Import Export in Drupal ). Un ulteriore sezione in cui vengono presentati le prove eettuate con un Web Service esistente (Prove con Energy-CHIT). Una sezione di conclusioni nali. Una glossario dove verranno inseriti i concetti e i termini non chiari a tutti. 5

6 2 I Sistemi CMS 2.1 I CMS Cenni Storici I content management system sono nati negli Stati Uniti e sono stati inizialmente sviluppati da alcune organizzazioni che producevano notevoli quantità di pubblicazioni, per il loro uso interno. Nel 1995 la CNET rese pubblici gli studi e i prodotti sviluppati internamente, distribuendoli con l'etichetta Vignette. La compagnia cominciò a mettere a disposizione il proprio software come sistema di gestione dei contenuti via web. Per la prima volta un utente poteva creare il proprio sito direttamente dal web, usando l'interfaccia CNET. Nel 1998, la Pencom Web Works, una compagnia di consulenza aziendale, introdusse il server di trasformazione dati (DTS) Metaphoria, che permetteva agli sviluppatori Java di scrivere applicazioni che si potevano collegare ai contenuti e permettevano di distribuire tali contenuti su canali diversi. Il prodotto non ebbe successo, ma il concetto che era stato introdotto costituì le basi di ciò che è diventato il CMS odierno Vantaggi e svantaggi dei CMS Vantaggi Un CMS permette di costruire e aggiornare un sito dinamico, anche molto grande, senza necessità di scrivere una riga di HTML e senza conoscere linguaggi di programmazione lato server (come PHP o ASP) o progettare un apposito database. L'aspetto esteriore delle pagine può essere personalizzato scegliendo un foglio di stile CSS appositamente progettato per un determinato CMS. I at le CMS, altrimenti noti come text-based CMS, sono dei content management system che si basano su le di testo (il più delle volte les XML) e che perciò non necessitano di alcun database come MySQL, PostgreSQL, ecc. Questi CMS sono facilmente installabili e dunque sono particolarmente adatti per siti personali o per piccole comunità. La maggior parte dei CMS sono opensource e quindi tutti i relativi vantaggi del software aperto. I Siti statici o vetrina sono semplici da realizzare per chiunque, sia che sia un programmatore web svogliato sia che sia un commerciante che voglia far conoscere la propria attività senza dover ricorrere ad una azienda di web-design. Per esempio il sito internet del gruppo Foppapedretti è stato realizzato in Joomla ( uno dei più noti CMS), il sito della squadra calcistica Sampdoria è stato realizzato anch'esso tramite un Content Management System. Il campo d'uso è veramente vasto e permette la pubblicazione di contenuti nelle forme più svariate a seconda delle esigenze. Svantaggi Un CMS è tanto più eciente quanto più è specializzato. Molti piccoli portali fanno ricorso a CMS (scritti da altri e messi a disposizione gratuitamente o a pagamento) di tipo generico; per quanto un CMS possa essere essibile, un sito basato su questa struttura in genere presenta un aspetto poco personalizzato se non è possibile intervenire direttamente sul codice sorgente per modicarlo. Analogamente i contenuti saranno sempre ancorati a quanto previsto da chi ha progettato il CMS e non alle esigenze di chi pubblica il sito. Problemi di gestione possono derivare dal fatto che chi pubblica o gestisce il sito può usare il CMS per intervenire sui contenuti e sull'aspetto, ma generalmente 6

7 (caso del software proprietario) non è in grado di intervenire direttamente (o far intervenire) sulla struttura del CMS stesso; questo è un limite strettamente connesso al vantaggio primario dei CMS: pubblicare un portale senza doverne progettare la struttura o senza possedere le conoscenze tecniche (o le risorse nanziarie) per uno sviluppo personalizzato. Tuttavia esistono anche CMS particolarmente evoluti che permettono di scrivere direttamente sul database. È il caso per esempio di alcuni CMS proprietari. Questi problemi sono risolvibili utilizzando software open source: la possibilità di accedere al codice sorgente del prodotto permette di personalizzare il software sulla base delle proprie esigenze a patto di non avere necessità di apportare modiche al prodotto adottato. Anche in questo caso, vanno messi in conto i costi per lo sviluppo di moduli personalizzati o funzioni particolari a meno di non possedere in proprio o nella propria struttura aziendale le conoscenze tecniche per intervenire nel codice sorgente. I portali di una certa importanza generalmente non fanno mai ricorso a CMS distribuiti bensì usano programmi e database progettati su misura, ovvero "CMS personalizzati" e dunque necessariamente specializzati; in questo modo la struttura e la presentazione vengono realizzate tenendo presenti i contenuti che il sito dovrà ospitare e potranno essere modicati in seguito a nuove esigenze. Un ulteriore problema riguarda l'integrazione con sistemi già esistenti, questo argomento sarà trattato nel dettaglio nella prossima sezione poiché è un aspetto critico dei CMS Gestione dei contenuti Per la gestione delle informazioni è necessario adottare una serie di passi: 1. Identicazione degli utenti di back end ( coloro che producono e pubblicano i contenuti ) e di fronte end ( coloro che beneciano dei contenuti ). 2. Impostazione delle varie responsabilità e dei vari permessi di accesso alla pubblicazione (in un grosso progetto sviluppato da numerose persone è necessario impostare privilegi e permessi di modica/lettura/scrittura). Inoltre è ragionevole pensare che, per determinati ambiti, anche la fruizione dei contenuti sia soggetta a restrizioni (forum, intranet aziendali, ecc). Tutto questo è possibile tramite la denizione di gruppi utenti e, più in dettaglio, tramite l'impostazione dei permessi per ogni singolo utente. 3. Il prodotto nale è il più delle volte costituito da componenti prodotti da più persone, quindi è necessario determinare un workow, che tramite procedure di supervisione permette l'assemblaggio dei vari pezzi in maniera semplice. Per poter rendere eciente la comunicazione tra i vari livelli della gerarchia, è necessaria un'infrastruttura di messaggistica, con la quale i gestori del contenuto possono ricevere notica degli avvenuti aggiornamenti. 4. Tracciamento e gestione delle versioni del contenuto 5. Pubblicazione dei contenuti 6. Gestione delle pubblicazioni delle varie sezioni del sito (Impaginazione, collegamenti, ecc). 7

8 2.1.4 I Web Content Management System Nonostante i CMS non siano stati concepiti per il Web, oggi il loro utilizzo più diuso è rivolto alla gestione di siti web, soprattutto se sono di grandi dimensioni e richiedono un frequente aggiornamento. Una delle applicazioni più utili dei sistemi di WCMS, infatti, è nella gestione dei portali (intranet, extranet, community, siti di e-commerce...), dove vengono impiegati come strumento di pubblicazione essibile e multiutente. Ad esempio, gestione di contenuti testuali (notizie, articoli ecc.), link, immagini, liste di discussione, forum, materiale scaricabile. Può essere modicata anche la struttura stessa delle pagine in numero ed organizzazione. A volte i WCMS danno la possibilità di gestire anche più versioni dello stesso sito (ad esempio, HTML o Mobile). I WCMS consentono di denire utenti, gruppi e diritti in modo da poter permettere una distribuzione del lavoro tra più persone. Per esempio, è possibile denire una classe di utenti abilitati esclusivamente all'inserimento delle notizie, mentre si può riservare la scrittura di articoli ad un altro gruppo, e limitare tutti gli altri alla sola consultazione. L'introduzione di un web content management system in azienda richiede la denizione di chiari processi interni di approvazione dei contenuti. La scelta di un software di WCMS è strategica per le aziende che generano la maggior parte di volume d'aari su Internet, ma, in proporzione diversa, è molto importante anche per il libero professionista che vuole utilizzare il medium Internet per farsi conoscere. In letteratura esistono numerosi modelli che aiutano a valutare il ritorno di un investimento in un WCMS. I costi di adozione sono spesso elevati, quindi non sono sostenibili per i professionisti o i privati che non fanno del Web la loro competenza di base. Per rispondere a questa necessità di mercato sono nati alcuni application service provider (ASP) che orono questo servizio direttamente via Web, senza richiedere alcun investimento hardware o software. Gli ASP costano ai loro clienti un canone annuale per il servizio di WCMS erogato. 2.2 Problemi di Integrazione L'integrazione dei CMS con dei web services già esistenti (non realizzati tramite CMS) è un problema delicato che apparentemente non sembra preoccupare ma che invece risulta un ostacolo piuttosto alto da scavalcare. Per comprendere al meglio il concetto è necessario fare una distinzione: Integrazione di CMS in Web Service. Integrazione di Web Service in CMS. La distinzione è obbligatoria poiché le due operazioni non sono aatto uguali, dieriscono in: procedure, vincoli e strutture dati. Integrare invece due web service realizzati tramite CMS è molto più semplice, a patto che siano stati implementati i moduli per il passaggio da un content type all'altro Cms to Web Service Ragionando per logica, inserire un CMS in un Web Service, signicherebbe unire due applicazioni web con strutture completamente diverse. Il web service che dovrebbe accorpare il Cms è costituito dai seguenti elementi: 8

9 Un Web Server che permette l'esecuzione del servizio; Pagine HTML; Script PHP/ASP/JSP; Un Database; Fogli di Stile CSS Il CMS possiede anch'esso tutti questi elementi ma vengono nascosti per denizione, cioè per far evitare all'amministratore di scrivere codice di qualsiasi tipo. A questo punto ci sono due possibilità per continuare il processo: 1. Se il CMS non è open-source c'è poco da fare, conviene abbandonare l'idea di utilizzare i CMS è continuare lo sviluppo del web-service esistente. 2. Se il CMS è open-source si può accedere al codice sorgente ed integrarlo con quello esistente, ma come si può intuire è un'operazione piuttosto lunga e complicata, specialmente se si pensa cosa succederebbe all'aumentare della dimensione del CMS. Per far comprendere più a fondo è meglio spiegare un esempio pratico: (a) Il web Service ed il CMS hanno due database diversi, con schema relazionale e tabelle diverse. Se trattiamo database con una decina di tabelle, è fattibile rifare il modello relazionale unendo i due precedenti, ma se invece stiamo trattando database con centinaia di tabelle? Non troverete nessuno, con un po di senno, che sia disposto a farlo. (b) L'esempio sopra citato calza perfettamente anche per il resto dei componenti (Pagine HTML, script PHP o JSP). In denitiva l'integrazione di CMS in un web service già esistente (realizzato con le tecniche comuni di programmazione web) è un operazione sconsigliabile a prescindere dalla situazione iniziale, conviene invece realizzare il contrario, ovvero integrare l'esistente web service in uno nuovo realizzato tramite CMS Web Service to CMS Il caso di integrazione di un web service in uno implementato tramite CMS è una via più immediata rispetto alla situazione precedentemente analizzata. Qualsiasi CMS open-source o non, potente o meno, mette a disposizione dell'amministratore una serie di strumenti per l'importazione chiamati Moduli (Per chiarire il concetto di modulo si rimanda alla sezione successiva I Sistemi CMS). Ovviamente non tutti i CMS mettono a disposizione gli stessi strumenti con la medesima potenzialità perciò è necessario scegliere con cura il CMS da utilizzare a seconda delle necessità che si hanno. I maggiori problemi che si posso arontare in questa situazione sono: Scelta del CMS adatto alle proprie esigenze. Identicare in maniera corretta il modulo che permette l'operazione necessaria. Gestire eventuali dipendenze del modulo in esame con altri moduli. 9

10 Risolvere eventuali problemi che il modulo solleva al momento dell'esecuzione. Rendere disponibile, ai vari gruppi di utenti, i contenuti che il modulo ha elaborato. Può capitare però che uno di questi punti sia un problema non risolvibile per una serie di motivi quali: Il modulo non garantisce la totalità delle nostre necessità > Possibile Soluzione: Ricerca di un altro modulo da aancare a quello già presente che svolga il mancante. A volte le dipendenze dei moduli creano conitti con altri moduli già presenti > Possibile Soluzione: Trovare una coppia di moduli che svolgano lo stesso compito e che non creano conitti La risoluzione dei problemi generati spesso non è possibile > Possibile Soluzione: Si ritorna alla scelta del modulo, cercandone un altro che svolga il medesimo compito e che non crei problemi. Se anche questa soluzione non porta a nessun risultato concreto allora bisogna necessariamente cambiare il risultato che si vuole ottenere. 2.3 I più usati e famosi CMS Joomla! Joomla! è un software di content management per siti web, realizzato completamente nel linguaggio PHP. È pubblicato con licenza open source GNU GPL v.2. È nato nel settembre 2005 da una scissione dal codice del CMS Mambo; attualmente è in rapido sviluppo, sotto la guida di un gruppo di sviluppatori (per buona parte ex-sviluppatori di Mambo) riuniti nell'associazione no-prot Open Source Matters Caratteristiche Il CMS è distribuito sotto forma di pacchetto compresso. È suciente scompattare l'archivio in una cartella pubblica di un server Web dotato di supporto a PHP ed avere a disposizione un database MySQL per i dati del programma. Dopo un processo di installazione (più propriamente, di prima congurazione) di pochi minuti, il sito è operativo. Tra le caratteristiche principali proposte ci sono: Alto grado di personalizzazione grazie ai numerosi moduli, componenti e mambot/plugin disponibili sia come Software libero che con altre licenze; Caching delle pagine per incrementare le prestazioni; Funzioni di Search Engine Optimization, per facilitare l'indicizzazione dei contenuti da parte dei motori di ricerca; Feeding RSS, che permette ai visitatori di essere avvisati degli aggiornamenti dei contenuti mediante l'utilizzo di un feed reader; 10

11 Versione stampabile delle pagine; Esportazione delle pagine in formato PDF; Pubblicazione tipo Blog; Sondaggi; Ricerca testuale su tutti i contenuti inseriti; Localizzazione internazionale, che permette la traduzione di ogni funzionalità del software nella propria lingua; Altri componenti open source disponibili separatamente, sponsorizzati dal team di sviluppo di Joomla! ma non sviluppati dallo stesso team consentono, fra le altre cose, di: Creare e gestire forum di discussione (Joomlaboard / Fireboard) ; Tradurre l'intero contenuto del sito per renderlo fruibile in più lingue (Joom!Fish); Migliorare la gestione degli utenti registrati e potenziare loro interazioni, creando un eetto community (Community Builder) Figura 1: Home Page di una Installazione di default di Joomla! 11

12 2.3.3 Estensioni Uno dei punti di forza di Joomla! è la vivacità della comunità che lo supporta, sia in termini di discussione e capacità di aiuto (il forum uciale supera i post mensili) che di ampia disponibilità di componenti aggiuntivi per personalizzare la funzionalità del motore. Tutte le estensioni vengono distribuite sotto forma di pacchetti compressi, la cui installazione è gestita in maniera completamente automatica da uno script apposito, disponibile nella sezione di amministrazione del proprio sito Joomla!, che permette anche di disinstallare estensioni già installate. Ne esistono di tre tipi: componenti, moduli e mambot. Molte estensioni (nell'ordine delle migliaia) sono scaricabili dall'archivio uciale Componenti I componenti di Joomla! sono estensioni speciche che permettono di aggiungere funzionalità complesse a un sito realizzato usando il CMS Joomla!. I componenti per Joomla! dieriscono dai moduli essenzialmente per il livello di complessità supportato. Tradizionalmente, i moduli vengono utilizzati per implementare funzionalità elementari mentre i componenti possono aggregare più moduli per realizzare funzionalità più complesse e più complete. In generale, l'aggiunta di un componente corrisponde all'aggiunta di un'intera sezione al sito dove viene installato. Per esempio, nel caso della gestione di una newsletter i moduli coprono funzioni tipo "iscrizione (aggiunta) di un nuovo utente", "descrizione (cancellazione) di un utente" eccetera mentre un componente potrebbe gestire la newsletter nel suo complesso. A loro volta, secondo il medesimo schema modulare, i componenti possono essere usati da applicazioni che coprono livelli di funzionalità ancora più complessi. I componenti possono essere realizzati da qualsiasi utente di Joomla!. In rete si possono inoltre trovare componenti già pronti, prodotti da sviluppatori indipendenti. Figura 2: La schermata di amministrazione di Joomla!. gestire tutti i Moduli e i Componenti del sito. Da qui è possibile 12

13 Per l'impiego di un componente riveste un ruolo fondamentale la versione di Joomla! per cui esso è stato sviluppato. Infatti, la versione Joomla! 1.0, per limitazioni intrinseche al framework, pone dei limiti anche alla complessità dei componenti, limiti che la versione 1.5 ha consentito di superare con l'adozione del modello MVC (model-view-controller). Un componente sviluppato espressamente per una specica versione di Joomla! viene detto anche "componente nativo" per quella versione. Fra la versione 1.0 e la versione 1.5 di Joomla! è supportata solo la compatibilità in avanti dei componenti, ossia è possibile usare su Joomla! 1.5 componenti originariamente sviluppati per Joomla! 1.0, grazie anche a un plugin chiamato Legacy Mode. L'uso di questo plugin può avere un impatto sul livello di sicurezza e sulle prestazioni dei componenti, tuttavia ha consentito di evitare la riscrittura di molti componenti nativi. I componenti nativi per Joomla! 1.5 non supportano la compatibilità all'indietro, non sono cioè utilizzabili su Joomla! 1.0, a causa dei notevoli cambiamenti al framework e per il cambio di modello. Si prevede che la versione Joomla! 1.6 supporterà la compatibilità all'indietro verso Joomla! Moduli I moduli di Joomla! sono estensioni che permettono l'aggiunta di piccole porzioni di HTML a un sito realizzato usando Joomla!. Sono usati per mostrare elementi di informazione o funzionalità interattive all'interno di un sito Joomla!, in maniera collaterale al contenuto principale. Si possono considerare come nestre aggiuntive attraverso le quali dare informazioni non necessariamente correlate alla pagina visualizzata, magari per mostrare le altre funzionalità del sito. I moduli recuperano le informazioni, o parti di informazioni denite attraverso parametri, e le visualizzano nella zona di loro competenza; ad esempio il modulo "ultime notizie" recupera di default i soli titoli degli articoli per visualizzarli nel sito come lista, dando la possibilità di anticipare al visitatore ciò che si trova all'interno del sito stesso e quali sono le notizie più recenti. All'utente viene data la possibilità di scegliere quali moduli visualizzare e dove collocarli all'interno del layout della pagina, in accordo con un template (vedi sotto). Moduli sono anche i menù di navigazione all'interno di un sito Joomla!. Agendo direttamente nella sezione Gestione Moduli (Module Manager) dell'amministrazione, possono essere creati semplici moduli in HTML. Nel caso di script più complessi, essi sono in genere preparati per essere installati con le apposite procedure. Esistono moltissimi moduli di grande utilità già programmati e pronti all'uso, messi gratuitamente a disposizione nell'apposita sezione del sito uciale delle estensioni. Fra i moduli standard si possono segnalare il modulo main menù (il menù principale), il modulo di login (per l'accesso riservato degli utenti), quello per i sondaggi (poll) e quello per la distribuzione dei feed RSS (syndicate). Generalmente, un modulo è composto da un le XML che funge da installer e che contiene le informazioni sullo sviluppatore dell'estensione e sugli altri le che lo compongono. È aancato da uno o più le PHP che ne svolgono la funzione principale, ovvero quella di generare il codice html che verrà poi riproposto sul sito. È possibile includere le.ini per consentire una più facile localizzazione del modulo. Tutti i le sopra elencati vengono poi compattati in un archivio di tipo.tgz o.zip, poi installabile sul CMS. 13

14 2.3.6 Template Un template è un documento HTML/CSS che contiene il codice necessario a guidare Joomla! e ad impaginare i contenuti: ad esempio contiene il codice che permette il caricamento dei vari moduli in posizioni predenite, codice per caricare il cosiddetto mainbody (la zona in cui vengono presentati i contenuti principali generati da Joomla! o dai componenti aggiuntivi) e cosi via. Per ottenere l'aspetto desiderato molti template contengono anche una serie di immagini (per gli sfondi, i bordi eccetera). Ogni template può essere scaricato da appositi siti gratuitamente o a pagamento ed installato attraverso l'apposita area admin Mambot I mambot sono nella versione 1.0 l'equivalente dei plugin della versione 1.5x, quando richiamati, attivano un programma, uno script o eseguono una specica funzione. Spesso agiscono in background nell'intero sito. Possono essere semplicissimi come la funzione che sostituisce un certo testo digitato con una funzione codicata (ad esempio posizionare una immagine precaricata impaginandola in un testo o spezzare in due pagine il contenuto di un lungo articolo), ma possono anche avere eetti molto più evidenti, come richiamare, all'interno delle nestre dei form per l'inserimento dei contenuti, le funzionalità di sosticati editor di testo in modalità WYSIWYG elaborati da terze parti. Possono inoltre permettere collegamenti tra diversi componenti; una galleria di immagini, ad esempio, può avere un mambot collegato che renda la descrizione delle immagini disponibile alle funzioni di ricerca sul sito. Esistono mambot per inserire funzioni Flash, per collegare automaticamente un glossario alle parole contenute nei testi degli articoli, per generare miniature delle immagini inserite nei testi in modo che alla selezione appaia una nestra con l'immagine a maggiore risoluzione, e molti altri. 2.4 Drupal Drupal è un content management system (CMS) modulare scritto in linguaggio PHP e distribuito sotto licenza GNU GPL. Drupal funziona su diversi sistemi operativi, tra cui Windows, Mac OS X, Linux e qualsiasi piattaforma che supporti i web server Apache e il linguaggio PHP. Drupal utilizza inoltre un database per memorizzare i contenuti, e necessita dunque di un software come MySQL e PostgreSQL che sono gli unici DBMS al momento supportati Storia Creato originariamente da Dries Buytaert come bulletin board system, divenne un progetto libero nel Il nome Drupal è la traslitterazione inglese per la parola olandese druppel che signica goccia. Il nome nasce dal defunto drop.org, sito il cui codice si evolse lentamente no a trasformarsi in Drupal. Buytaert voleva chiamare il sito dorp (In olandese villaggio, riferendosi all'orientamento per community del progetto), ma commise un errore di digitazione quando controllò la disponibilità del dominio. Rileggendo, decise che drupal suonava meglio. Negli anni Drupal ha acquistato popolarità. Da maggio 2006 ad aprile 2007, Drupal è stato scaricato più di volte. Ora lo sviluppo di Drupal 14

15 gode dell'apporto di una grande comunità. Dal novembre 2009 il sito della Casa Bianca WhiteHouse.gov utilizza Drupal Struttura Una volta installato sulla macchina, drupal presenta una home page come quella mostrata nella gura sottostante. Figura 3: Home Page di una Installazione di default di Drupal La pagina mette a disposizione 4 servizi principali: Accedere alla sezione di Amministrazione, dove è possibile gestire tutte le regole per qualsiasi contenuto o modulo del sito Figura 4: Sezione di amministrazione, da qui è possibile raggiungere qualsiasi impostazione del sito. 15

16 Accedere alla sezione di gestione dei Moduli, dove è possibile abilitarli/disabilitarli oppure scaricarne di nuovi. Figura 5: Sezione di Gestione dei Moduli. Gestire la parte di Design Graco tramite la sezione Temi. Figura 6: Parte di Gestione dell'aspetto graco del sito. 16

17 Inserire un nuovo contenuto informativo all'interno del nostro sito. Figura 7: Creazione di contenuto in Drupal tramite i contenitori di Default (Pagina e Storia) Drupal, per essere usato correttamente, richiede l'apprendimento del concetto fondamentale di funzionamento: in Drupal tutto ruota ai Moduli e ai Contenuti; il Data Base è secondario poiché viene gestito automaticamente da Drupal( Non è assolutamente necessario conoscere SQL). Vedremo nelle sezioni successive l'approfondimento di questi concetti. 17

18 2.4.3 I Moduli I Moduli sono dei plugin aggiuntivi che estendono le funzionalità predenite di drupal. Appena installato Drupal contiene veramente poco di utile quindi, è necessario, portarsi subito alla pagina di download dei componenti aggiuntivi, dove, oltre all'elenco dei moduli più scaricati, esiste un veloce e comodo motore di ricerca, che ci porta subito all'argomento desiderato. Come Funzionano? I Moduli sono dei pacchetti di codice Php che eseguono diverse funzionalità. Drupal è comandato da un processo core chiamato cron, questo processo è stato progettato con un sistema di hook (ganci) o callback, che permettono ai moduli sviluppati dalla comunità di inserire funzioni nel processo di esecuzione di Drupal. I moduli, così gestiti, non creano pericoli, poiché non hanno il pieno controllo del core. Come si Installano? I Moduli scaricati vengono salvati sulla propria macchina come archivi (.tar.gz); una volta scompattato, la directory risultante va posizionata della directory di Drupal nella sotto cartella chiamata /modules. A questo punto basta comandare un refresh al web server(in modo che carichi i nuovi le), posizionarsi nella sezione di amministrazione dei moduli e con un semplice click abilitare il modulo che abbiamo appena scaricato ed importato all'interno di drupal. Ostacoli? Ci sono due possibili ostacoli che si possono presentare durante l'installazione di un modulo: 1. Il modulo non è compatibile con la versione di Drupal installata. > Ritornare sul sito e cercare la versione compatibile, altrimenti abbandonare il modulo e cercarne un altro che svolga lo stesso compito ma che sia aggiornato. 2. Nel caso stessimo per attivare un modulo, come è ragurato nella gura seguente, può capitare che il modulo abbia delle dipendenze. A questo punto è necessario scaricare ed attivare il/i modulo/i richiesto/i dal modulo di partenza per poter continuare il processo di attivazione. Questo può risultare scomodo e poco eciente poiché all'aumentare delle dimensioni del sito, aumentano i moduli utilizzati e quindi anche i moduli passivi (quelli richiesti come dipendenza). Tutto ciò può portare confusione all'interno della pagina di amministrazione dei moduli e anche al calo di prestazioni del web server. 18

19 Figura 8: Dipendenza nel modulo Node Import, richiede infatti Date API e Advanced Help Vantaggi Un modulo, rilasciato da poco, integrato totalmente nel core di Drupal chiamato update_status notica automaticamente il gestore del sito quando vengono rilasciate nuove versioni dei moduli e temi installati. Questo evita un lavoro manuale di ricerca periodica di aggiornamento assai lungo e tedioso. Inoltre la comunità di Drupal ha sviluppato moduli per: Sistemi e-commerce ; Flusso di lavoro redazionale; Gallerie fotograche ; Gruppi autogestiti ; Sitemap di Google ; Gestione di mailing list ; Integrazione con CVS ; Gestire immagine e video ; 19

20 Gestire servizi di terze parti (Adsense, AuctionAds, Technorati, etc.); Aggiungere funzionalità Javascript ed Ajax Contenuti Il Contenuto in Drupal è esattamente ciò che esprime la parola stessa. Nel caso di un blog saranno post, nel caso di un sito vetrina saranno le notizie, la presentazione dell'attività, ecc. A livello di amministrazione, in Drupal, non si deniscono i Contenuti ma i Contenitori, cioè le strutture che andranno a contenere i contenuti. Se si vuole far una paragone con la programmazione a oggetti, i Contenuti sono istanze di classi Contenitori. Di default in drupal ci sono due tipi di contenitori: Pagina: Una pagina (page), simile come struttura a una story, è un metodo semplice per creare e mostrare informazioni che raramente vengono cambiate, tipo una sezione Chi siamo di un sito web. Come impostazione predenita, una pagina non prevede commenti dei visitatori e non viene mostrata nella home page iniziale del sito. Storia: Una storia, simile come struttura a una pagina, è ideale per creare e mostrare contenuti che coinvolgano o informino i visitatori. Comunicati stampa, annunci ed altri contenuti simili al blog possono essere creati con la voce storia. Come impostazione predenita, una storia viene automaticamente mostrata sulla pagina principale del sito ed è possibile aggiungervi commenti. Come balza all'occhio questi due tipi di contenuti sono molto scarni e permettono poco rispetto a quello che si può fare con del codice HTML+ SCRIPT. Per questa motivazione la comunità di Drupal ha messo a punto e poi pubblicato un modulo chiamato CCK (Content Construction Kit). Questo modulo si integra nella sezione Tipi di Contenuto e permette appunto la creazione di Content type customizzati. Una volta terminata la procedura di creazione di un nuovo Content Type, Drupal creerà due tabelle nel proprio Database; in una ci sarà l'elenco dei campi inseriti, nell'altra invece ci saranno i dati veri e propri codicati secondo le politiche di Drupal per non renderli in chiaro. Si Rimanda alla sezione Prove Energy-CHIT per un esempio pratico di creazione di un Custom Content Type. 20

21 2.4.5 Viste Fino a questo punto abbiamo visto come interagire con Drupal per elaborare procedure(moduli) e per immagazzinare Dati (Contenuti). Per completare un completo processo di pubblicazione di contenuti su web manca all'appello una procedura per visualizzare i dati contenuti nel database oppure i risultati di una elaborazione. Per questa necessità sono state sviluppate le Viste che sono niente meno che delle Query SQL sul database. Per rimanere nei preconcetti di un CMS (Chiunque può sviluppare siti web), le viste non chiedono assolutamente comandi SQL, ma propongono all'amministratore una semplice ed intuitiva interfaccia graca. Grazie ad un wizard, con pochi passi, si possono recuperare tutte le informazioni necessari. L'unico limite è che si possono interrogare tabelle di cui si è i proprietari, cioè tabelle che derivano dalla creazione di un Custom Content Type oppure che derivino da strutture dati standard; le tabelle private di Drupal non si possono interrogare per ovvi motivi di sicurezza interna. Per un esempio pratico di creazione di viste in Drupal si rimanda anche in questo caso alla sezione Prove Energy-CHIT. 21

22 3 Import/Export in Drupal I moduli sono importanti per un CMS come lo è il carburante per un motore a scoppio; senza di essi il CMS non ha funzionalità e quindi non ha ragione di esistere. Nel mio elaborato ho arontato la categoria di moduli più critica: la fase di Import / Export. Questa categoria è stata classicata critica poiché il CMS, attraverso i moduli opportuni, deve riuscire ad interagire con componenti a lui estranei, scritti in altri linguaggi e dagli scopi più vari. La comunità di Drupal ha sviluppato nel corso nel tempo, e sta ancora sviluppando, una quantità notevole di moduli per garantire l'integrazione in Drupal. Uno dei fattori più interessanti è che, nella comunità degli sviluppatori, esiste uno spirito di collaborazione elevatissimo; quando parte un progetto per un nuovo modulo, la partecipazione è altissima, sia che sia un progetto utile a pochi sia che sia uno nuovo che possa aiutare numerose persone. Nella mia analisi ho estratto un insieme ridotto di moduli giudicati signicativi per far comprendere in maniera pratica le potenzialità di uno dei migliori CMS esistenti. Per rendere più facile la comprensione di ogni singolo modulo, questa sezione verrà divisa in tante sottosezioni quanti sono i moduli; ogni sottosezione conterrà un modulo descritto nelle sue caratteristiche. 3.1 Backup and Migrate Backup and Migrate semplica l'attività di backup e di ripristino del database di Drupal, permette inoltre di spostare il database da un sito in Drupal ad un altro. Supporta i formati di compressione bzip,gzip,zip e permette di eettuare backup programmati. Caratteristiche: Backup e ripristino di più database alla volta Upload del backup su server FTP/ Programmazioni di backup multiple su più database Crittograa AES per i backup 22

23 Figura 9: Operazione di Backup sul database selezionato Come si può vedere dall'immagine sopra l'operazione di backup è accompagnata da quella di restore. Inoltre è possibile scegliere la destinazione del le di backup e chi può eettuare tali operazione. L'ultima caratteristica permette invece di eettuare backup programmati. Il Modulo funziona perfettamente, ogni sua caratteristica raggiunge il suo scopo. Ovviamente all'aumentare delle dimensioni del database l'operazione di backup/restore sarà più lunga ma porta comunque ad un risultato certo. Il Modulo è funzionante sulla versione stabile di Drupal ed è in fase alfa per la nuova versione 7 di Drupal che è ancora in fase di sviluppo. 3.2 Printer, and PDF versions Il Modulo permette di esportare ogni nodo del sito in 3 formati diversi: In un formato web, come una pagina internet salvata in locale; In formato PDF; Come un link web spedibile via (viene mandato il link completo del sito per la visualizzazione del nodo). 23

24 Figura 10: La gura mostra il modulo installato e pronto all'uso. Oltre alla possibilità di eseguire uno dei 3 export esiste un ulteriore tab che permette di gestire le Impostazioni; è possibile impostare un foglio di stile CSS per impaginare e presentare l'export, gestire il formato degli url inviati ed abilitare javascript per la visualizzazione della pagina (nel caso fosse necessario).viene richiesto inoltre, per la fase di esportazione in pdf, di indicare un software di generazione di PDF installato sulla macchina poiché il servizio non è integrato nel modulo. Il Modulo non è particolarmente articolato ma molto utile nel caso in cui si voglia esportare i contenuti del proprio sito (presentazioni, condivisione del proprio lavoro nel team di sviluppo, ecc ). Potrebbe essere arricchito inserendo nuovi formati di export come CSV ed XML ma esistono già altri moduli che permettono questa cosa. 24

25 3.3 User Import La scopo del modulo consiste nell'importare nel sito utenti tramite un le CSV (Comma Separated Value). L'operazione di import permette di aggiungere nuovi utenti oppure di aggiornare quelli esistenti. In Drupal gli utenti sono nodi con una struttura di default inseriti in una tabella privata del database. Figura 11: Lo User Import è formato da 3 sezioni, in questa gura viene mostrata la principale: L'import da CSV. Una prima sezione mostra tutte le importazioni no ad ora eettuate, la seconda, che è la principale, permette di importare un CSV contenente la lista degli user; una terza permette di settare due parametri: il numero massimo di user importabili per volta e il numero massimo di utenti contenuti in un singolo le. Sono due parametri legati alle prestazioni; il primo concerne il fatto che quando un utente viene importato riceve una di notica che informa dell'avvenuta registrazione al sito, il secondo invece riguarda solo il fattore busy della macchina che è impegnata nell'importazione. Il Modulo viene usato per Import di grosse moli di utenti, evita infatti l'inserimento manuale tramite il form di amministrazione del sito. Molto utile per la migrazione della tabella utenti da un database all'altro. Per una corretta operazione di Import è necessario che il le CSV sia sintatticamente corretto (ogni dato separato da virgole, ogni tupla separata da un carattere di a capo). Come si può intuire esiste il modulo inverso che permette lo User Export, chiamato Prole CSV. Questo modulo è praticamente uguale all'import, dierisce ovviamente nella direzione dei dati. 25

26 3.4 Taxonomy import/export via XML Questo modulo permette di importare ed esportare vocabolari e termini tassonomici tramite XML, CSV, RDF e altri formati. Il modulo ha una dipendenza verso il pacchetto Taxonomy che è installato da drupal di default. Per questo motivo l'interfaccia per l'import/export via XML viene integrato nella sottosezione Taxonomy che è già presente nella pagina di amministrazione del sito. Il modulo 'taxonomy' permette di suddividere in categorie i contenuti utilizzando sia tag inseriti dall'utente, sia categorie denite dall'amministratore. E' uno strumento potente per classicare i contenuti, con molte funzionalità avanzate. Figura 12: Modulo aggiuntivo per l'esistente 'Taxonomy' che permette l'import/export di vocaboli/vocabolari tassonomici via XML Tutt'ora lo sviluppo di questo modulo è molto attivo, poiché la tassonomia rappresenta uno dei punti forti di un sistema Cms; gli sviluppatori stanno cercando di aggiungere al modulo la funzionalità di supporto remoto così da poter ricevere via web intere librerie di termini. Un ulteriore idea di sviluppo sarebbe che ogni sito Drupal diventi un server tassonomico per rendere il le sharing di vocabolari e termini più aperto è decentralizzato. Dalle molte prospettive future presenti, il modulo sarà nelle versioni future uno dei must to have per un amministratore di Drupal. Il modulo è stabile e funzionante nella versione corrente di Drupal mentre non si hanno aggiornamenti sullo sviluppo per la nuova release di Drupal 26

27 3.5 Taxonomy CSV import/export Questo modulo non è un overriding di quello precedente, bensì è un'alternativa. Quando si desidera importare un vocabolario, una tassonomia o una semplice lista di termini nel sito Drupal, si hanno due scelte principali: taxonomy_xml o taxonomy_csv. Taxonomy_xml è perfetto per importare tassonomie e vocabolari standardizzati, nonostante il nome è possibile importare/esportare anche le CSV ma formattati secondo il formato ISO In alternativa se si vuole importare vecchi vocabolari e termini non standardizzati è necessario utilizzare Taxonomy_csv. Una volta importato il necessario è possibile esportare i contenuti utilizzando tranquillamente taxonomy_xml, infatti anche taxonomy_csv si integra perfettamente nel modulo standard 'Taxonomy'. Figura 13: Taxonomy CSV import/export si integra nel modulo di default 'Taxonomy', esso a dierenza del taxonomy_xml permette di gestire una serie di parametri per l'import di tassonomia non standardizzata Tramite un veloce ed intuitivo form da compilare è possibile importare qualsiasi tipo di tassonomia è standardizzarla per renderla utilizzabile secondo i formati già esistenti. Il modulo oltre a funzionare perfettamente è già in Beta anche per la prossima versione di Drupal. 27

28 3.6 Views Datasource Views Datasource è un set di plugin per le viste in Drupal, esso permette di esportare i contenuti delle viste in un certo numero di formati condivisibili basati su XML,JSON e HTML. Questi tipi di formati permettono l'accesso ai dati delle viste da parte di client web alla ricerca di semantica. Il modulo è formato da 4 plugin per le Viste: 1. views_xml - Output come righe XML, OPML, e Atom; 2. views_json - Output come JSON, JSONP/JSON come script; 3. views_rdf- Output come FOAF, SIOC, e DOAP; 4. views_xhtml - Output come hcard, hcalendar, e Geo. Per essere installati questi plugin richiedono come dipendenza il Modulo 'Views' che serve appunto per creare Viste. Il Modulo purtroppo è in fase beta e non funziona, le impostazioni per settare l'esportazione non vengono visualizzate all'interno della sezione Viste e quindi non è possibile testare i plugin. Nonostante il bug questo progetto ha buone potenzialità se portato a termine con successo poichè può rendere accessibili i contenuti a numerosi web service anche se essi lavorano con formati di dato diversi. 3.7 Custom Reports Custom Reports è stato creato per permettere al client collegato al sito Drupal di scaricare dati dal database, questo è permesso tramite delle Custom Views. Questo modulo è stato creato principalmente per gli sviluppatori. Il modulo va a completare le viste per quanto riguarda le interrogazioni al database; questo perché il wizard delle viste permette di eettuare solo query semplici. Il Modulo è stato creato per due semplici ma importanti scopi: Accedere a tabelle che non sono accessibili tramite le 'Viste' (Il modulo viste non permette le interrogazioni su tabelle private di Drupal); Permettere la creazione e l'esecuzione di Query SQL Complesse; 28

29 Figura 14: La schermata per la creazione di un Custom Report Il Modulo funziona nel seguente modo: Usa un esistente custom content type, o ne crea uno nuovo nel caso fosse necessario; Si crea un custom report node (Tramite l'interfaccia), gli si da un nome e si incolla nella text area il codice SQL precedentemente creato; Si accede alla tabella utenti e si danno i permessi per visualizzare il report; Gli utenti quando visiteranno la pagine del report potranno scegliere il formato di export ( di default sono abilitati CSV e XML ma si possono inserire altri tipi). Custom report è di massima utilità, capita spesso di dover creare interrogazioni abbastanza complesse e data la lacuna delle viste è stato necessario sviluppare questo modulo. Non presenta problemi di funzionamento ed è stabile per la versione corrente. L'unico problema è che per utilizzare queste custom views è necessario conoscere il linguaggio SQL e come i database funzionano; questo va un po' contro la natura dei CMS ma purtroppo altre soluzioni per questa necessità al momento non esistono. 29

30 3.8 Views Importer View Importer permette di importare viste precedentemente esportate in maniera davvero semplice. Questo modulo si comporta come una sorta di plugin per il modulo Viste aggiungendo nell'interfaccia dell'ultimo una 'tab' che gestisce l'import. Figura 15: L'import di viste viene integrato nel modulo 'Viste' Questo modulo permette l'import in due modi dierenti: 1. Tramite la sezione di amministrazione delle viste, dove si inserisce il titolo e il codice della vista precedentemente esportata. 2. Il modulo nel suo path di installazione dentro drupal possiede una cartella chiamata import, nella quale è possibile inserire le di testo contenenti il codice delle viste esportate; quando si va ad attivare il modulo da Drupal esso viene installato e con esso vengono anche importate le viste contenute nella cartella. Questo è un modo veloce nel caso si hanno un set notevole di viste da importare. Il modulo è utile nel caso di migrazione parziale o totale del sito, nel caso di clonazione su diverse macchine di sezioni vitali del sito che non possono subire inoperatività. L'operazione di export delle viste non è stata implementata in un modulo specico ma è integrata direttamente nel modulo 'viste' come funzione per le views esistenti; la funzione permette di copiare ed incollare in un le di testo il codice della vista visualizzato all'interno di una pagina nell'amministrazione delle viste. 30

31 3.9 Save To FTP Il Modulo permette di salvare il contenuto di un nodo su un server FTP, in formato.html, esso inserisce inoltre eventuali le aggiuntivi necessari al nodo(fogli di stili CSS, js, immagini). Figura 16: Il Modulo Save To FTP pronto per essere utilizzato Il modulo nella fase iniziale prevede di poter inserire in formato HTML informazioni nell'header, prima e alla ne del body. Inne si inseriscono le informazioni del server FTP come riportato nella gura sotto. Figura 17: Fase di inserimento dei dati del server FTP, spesso è la medesima macchina dove viene hostato il sito. 31

32 I Principali utilizzi sono i seguenti: esportazione delle pagine statiche e dinamiche; tenere lo storico del cambiamento delle pagine nel corso del tempo; condividere il proprio lavoro con chi lo necessità in un modo rapido e senza perdere dati. L'utilità è ristretta al solo fatto di poter caricare nodi su FTP, se non si trova un'applicazione di questo modulo all'interno del proprio sito web è piuttosto inutile. Usarlo invece è davvero semplice ed in pochi passaggi si è in grado di caricare del contenuto su FTP. 32

33 3.10 Node Table NodeTable è un modulo per la gestione di tabelle HTML in siti Drupal. Il modulo fornisce funzionalità per la creazione, il caricamento, la modica e la presentazione di tabelle HTML all'interno di nodi o come nodi. Figura 18: Il modulo inserisce un nuovo content type usufruibile per la gestione di tabelle HTML Crea un nuovo content type e lo inserisce assieme a quelli di default (Storia e Pagina) fornendo all'amministratore un considerevole numero di funzioni, quali: Inserire tabelle HTML all'interno del nodo bloccandone il contenuto attraverso dei ltri; Generazione automatica di markup HTML relativo alla tabella; Inserimento di tabelle nel 'nodetable' tramite le CSV; Esportazione delle tabelle in formato CSV; Creazione manuale di 'nodetable' all'interno del menù di amministrazione dei contenuti; Generazione automatica degli Headers HTML; Permette l'ordinamento di una o più colonne in modo essibile (asc/desc,tramite altri ltri di default o condizioni customizzate); Permette la creazione, la modica o la cancellazione di una qualsiasi riga o colonna della tabella; Permette il riordinamento delle righe tramite drag and drop (funziona solo se non ci sono ltri applicati sulle colonne); 33

34 Inserisce automaticamente un ID identicativo per ogni tabella inserita e per eventualmente anche per ogni riga della tabella; Permette l'inserimento di codice HTML per ogni singola cella della tabella, per applicare stili di formattazione, di visualizzazione etc. Possiede una robusta struttura di permessi che controlla le operazioni sulle tabelle (aggiungi/modica/cancella); Il Modulo purtroppo è in fase 'alpha' e non tutte queste caratteristiche funzionano perfettamente; inoltre il modulo si avvale di alcuni script Javascript per l'ordinamento e per l'import/export dei csv, quindi l'esecuzione risulta più lenta e laboriosa rispetto alle altre operazioni. Tuttavia l'importanza di questo modulo è innegabile poiché le tabelle sono ovunque sul web. Da sottolineare la procedura di import/export di tabelle tramite CSV, utile nel caso di integrazione di un sito web costruito 'normalmente' in uno realizzato tramite Drupal. 34

35 3.11 CCK Importer CCK Importer permette di importare nel proprio sito Drupal custom content type precedentemente esportati. La funzione si va ad integrare nella sezione d'amministrazione tipi di contenuto e si identica tramite l'aggiunta di una tab 'Importa' nel menù di navigazione. Figura 19: La funzione 'Importa' per i Custom Content Type L'utilizzo è semplicissimo, si può specicare il tipo dei campi da importare oppure crearne uno nuovo se non esiste uno uguale già creato; inne si incolla nella text area il codice precedentemente esportato. A questo punto nella sezione tipi di contenuto si ha il nuovo tipo appena importato. Il Modulo è davvero utile nella migrazione di database che utilizzano custom content type(cct), infatti evita di dover re-impostare i nuovi tipi sul nuovo DB. Una eventuale miglioria nel modulo potrebbe permettere l'importazione multipla di CCT Views Node Feed Il modulo permette di creare dei feed per le viste create, inoltre è possibile specicare un qualsiasi codice di markup (JSON,XML,ecc.) invece dell'rss. L'obbiettivo del modulo è quello di rendere disponibile i contenuti del sito a cui è applicato tramite dei feed; in questo modo l'utente utilizzatore del sito può tenersi aggiornato sui contenuti sottoscrivendosi ai feed che l'amministratore del sito rende disponibili. Purtroppo il modulo è compatibile con la vecchia versione di Drupal e non è stato possibile testarlo. Nonostante l'impossibilità di testare il modulo, la scopo del progetto è molto rilevante. I Feed sono oggigiorno usati su larga scala portando numerosi beneci, un amministratore di un sito web costruito tramite Drupal dovrebbe avere la possibilità di usare tale tecnologia per mettere in luce il proprio portale. Il team di sviluppo non ha rilasciato dichiarazioni relative ad un eventuale implementazione del modulo per la versione corrente o per quella futura di Drupal. 35

36 Figura 20: Views Node Feed non è compatibile con la versione attuale di Drupal 3.13 Joomla To Drupal Joomla to Drupal permette la migrazione di un sito web sviluppato in Joomla verso uno creato in Drupal. Figura 21: Il modulo richiede di congurare alcuni parametri necessari all'operazione di migrazione 36

37 Figura 22: Le opzioni congurabili non sono poche e permettono una migrazione accurata Il modulo permette di spostare i contenuti di maggior rilevanza quali: La tabella utenti Sezioni e categorie, essi vengono tramutati in vocabolari tassonomici o termini. I 'Content Items' di Joomla vengono tramutati in nodi leggibili da Drupal. Oltre a spuntare quali elementi si vuol importare l'interfaccia di congurazione del modulo chiede inoltre di impostare: Se aggiornare eventuali elementi già importati prima; I parametri di Joomla quali: L'indirizzo del server Joomla; Il Nome del database Joomla; Username e Password dell'account di amministrazione del database Joomla; Un eventuale path della cartella Home del sito Joomla( nel caso in cui non si trovi nella /public). Ulteriori parametri riguardanti i tipi di Content, il formato di Input e le impostazini di Import. Il Modulo è ancora in fase Alpha e quindi non è molto stabile, infatti casualmente il processo di import si interrompe inaspettatamente. Tuttavia il modulo propone grandi vantaggi nella prospettiva di migrazione da Joomla a Drupal. Sarebbe ulteriormente vantaggioso se fossero implementati altri moduli per la migrazione da e verso i maggiori CMS tutt'ora presenti, per realizzare ciò è assolutamente necessaria la collaborazione degli sviluppatori di ogni CMS. 37

38 4 Prove con il portale Energy CH-IT 4.1 Cos'è l'energy CH-IT L'energy CH-IT è un progetto per il risparmio energetico nelle aziende tra la provincia di Como, Varese ed il canton Ticino. E' questo il progetto, nanziato nell'ambito del Programma di cooperazione Italia-Svizzera , che la Camera di Commercio di Como sta avviando in collaborazione con Politecnico Milano, Fondazione Politecnico, Api Servizi Varese, Centro Tessile Cotoniero e Abbigliamento e la SUPSI (Scuola Universitaria Professionale della Svizzera Italiana). Il progetto ore gratuitamente alle aziende presenti sul territorio delle diagnosi sui consumi termici ed elettrici per far emergere eventuali aree di inecienza ed identicare i possibili interventi di risparmio energetico realizzabili. Il Progetto è stato portato anche sul web all'indirizzo Il sito web è stato realizzato con le tecniche comuni di programmazione web e, proprio per questo motivo, è stato scelto come cavia per arontare la migrazione verso un CMS. Il 'cuore' del portale consiste in un database contenente tutte le informazioni delle aziende che si sono iscritte al progetto; il 'goal' del mio lavoro è stato quello di riuscire ad importare il database del sito nel CMS Drupal per testare il funzionamento dell'importazione. Prima di arontare il tema principale appena descritto è meglio analizzare gli strumenti che sono stati utilizzati per realizzare il test. 4.2 Moduli per l'import di database in Drupal Per realizzare l'import di database nel CMS Drupal è stata fatta un'analisi dei moduli che la comunità di sviluppatori ha realizzato per arontare questo tipo di problema. La scelta dei moduli da poter utilizzare è stata inoltre condizionata dal formato dei dati che devono essere importati; dopo una serie di colloqui con gli amministratori del portale si è concluso che il formato reso disponibile fosse quello.xls (Microsoft Excel). Nell'insieme dei moduli disponibili nella comunità, moduli per la gestione diretta di le.xls non esistono, sono disponibili però alcuni strumenti per la gestione di le.csv. Con una semplice conversione tramite comunissimi software è possibile ottenere le.csv da.xls. I moduli trovati per eettuare l'import di le.csv sono 2: Sheetnode Node Import Necessaria l'analisi dettagliata di questi due moduli che rappresentano il mezzo per arrivare allo scopo pressato. 38

39 4.2.1 Modulo Sheetnode Sheetnode è uno dei moduli più complessi presenti fra quelli disponibili. Esso infatti, a dierenza di quasi tutti gli altri moduli di Drupal, non è un 'semplice' modulo scritto solo in php ma necessità di eseguire contenuti Java. Per questo motivo Sheetnode, al momento dell'installazione, necessita di una serie non banale di passaggi di congurazione. Questo alto livello di dicoltà è dato dal fatto che il modulo una volta installato presenta un'interfaccia simile a un foglio di calcolo permettendo diverse funzioni quali: Creare nodi, ogni nodo è un foglio di calcolo completo comprendente formule e formattazione delle celle; Riferimenti incrociati tra celle di nodi diversi; Integrazione completa con il motore di ricerca interno di Drupal (per cercare contenuti all'interno delle celle); Import/Export di le.xls (Funzione che richiede java); Esportazione diretta in formati OpenOce; Importazione di fogli di calcolo da Google Docs; Creazione di viste che riportano i risultati direttamente in fogli di calcolo, visualizzando correttamente formule utilizzabili ed eventuali graci; Esportazione delle viste create in formati compatibili con Excel/OpenOce e GoogleDocs. 39

40 Figura 23: Esempio di nodo visualizzato come foglio di calcolo 40

41 Il modulo, come illustrato in gura sotto, richiede per funzionare correttamente l'installazione di un PHP/JAVA Brigde. Nonostante che il modulo non sia totalmente dipende da codice Java, per sfruttare le funzionalità più interessanti necessita di tale caratteristica. Questo ponte, come si può intuire, permette la comunicazione tra il modulo (in php) e le classi (in java) che servono per gestire le varie funzioni del foglio di calcolo e il foglio di calcolo stesso. Figura 24: Dipendenza da PHP/JAVA Bridge richiesta da SheetNode per poter funzionare in tutte le sue funzionalità Questo 'Ponte' risulta il punto cruciale per il funzionamento generale del modulo. All'interno della pagina del modulo, sul sito web di Drupal, esiste una guida creata dagli sviluppatori per installare correttamente il bridge; purtroppo questa guida è molto generica e la buona riuscita dell'installazione non è assicurata. In denitiva l'utilizzo del modulo SheetNode è stato abbandonato per una serie di motivi: Non è stato possibile installare il bridge perché la nuova versione non è compatibile con la versione attuale del modulo sheetnode (gli sviluppatori dei due componenti sono diversi e a quanto pare non sono per nulla allineati); tutt'ora non si hanno notizie riguardo ad aggiornamenti nel modulo. L'unica soluzione sarebbe quella di reperire in rete la versione precedente del bridge, ma purtroppo la ricerca non ha dato esito positivo. Anche se i vari tentavi avessero portato ad un risultato concreto non sarebbe stato possibile usare questo modulo poiché alcuni vincoli sulla macchina ospitante il sito Drupal impossibilitano l'esecuzione di codice Java (questo è stato scoperto in seguito ed ha comportato l'inutilità di alcuni giorni di lavoro). Avendo lavorato molto con questo modulo posso concludere che, se l'installazione avesse avuto buon esito e che la macchina ospitante fosse libera da vincoli, il 41

42 modulo possiede alte potenzialità per una gestione completa ed user friendly di fogli di calcolo proprio come avviene sui comuni software Node Import Node Import permette di importare dati da un un le.csv(comma Separated Value) o.tsv (Tab Separated Value). Come vincolo unico richiede che i le siano formattati secondo la codica UTF-8. Per essere abilitato inoltre il modulo richiede due dipendenze: verso il modulo 'advanced help' che fornisce una specie di help per l'uso di alcuni moduli; verso il modulo 'date API' che, anch'esso per una serie di moduli, controlla il usso temporale delle operazioni. Il modulo, rispetto al SheetNode, è molto più semplice da usare; si integra nella pagina di amministrazione di Drupal inserendo la voce 'Import Content'. Esso è composto da 3 sezioni principali: 1. Una sezione 'Elenco', dove viene elencato uno storico degli import eettuati; 2. La sezione principale 'New Import', che permette di inizializzare una nuova importazione; 3. Una sezione 'Impostazioni', dove è possibile eettuare alcuni setting quali: (a) La cartella dove posizionare i le da importare; (b) La possibilità di fare l'upload dei le da importare sul server FTP (questa opzione serve per caricare le da remoto); (c) Le estensioni dei le accettate dal modulo; (solo estensioni di le di testo). Figura 25: Sezione di Impostazioni del modulo Node Import 42

43 La fase di 'New Import', che è il cuore del modulo, verrà analizzata nel dettaglio nella pagine a seguire dove verranno descritte le prove eettuate con i vari moduli per raggiungere lo scopo di questa tesi, la migrazione del database. 4.3 Creazione di un nuovo content type tramite il modulo CCK Il modulo Node Import, per essere utilizzato, richiede in una delle prime fasi dell'importazione di specicare il tipo di contenuto che esso andrà ad importare. Per questo motivo prima di iniziare l'operazione di Import è necessario creare un nuovo 'tipo di dato' sfruttando il modulo ad hoc CCK (Content Construction Kit). Il modulo si integra nella sezione d'amministrazione 'Tipi di contenuto' e, la sua corretta installazione, è identicabile tramite il tab 'Aggiungi nuovo tipo di contenuto'. Figura 26: Fase iniziale della creazione di un Custom Content Type Dopo una serie abbastanza intuitiva di parametri da impostare, nell'elenco dei Content Type, verrà mostrato il nuovo tipo di dato appena creato. Il passo successivo consiste nel modica dei campi del nuovo tipo di dato azionando il comando 'manage eld' posto alla ne della riga di ogni content type. La pagina mostrata permette 3 azioni sui campi del content type: Creare un nuovo campo; Cancellare un campo esistente; Modicare l'ordine dei campi; Creare un gruppo di campi, cioè indicare a Drupal che un certo numero di campi sono relativi ad un medesimo concetto. Per esempio il numero di telefono dell'azienda e il numero di cellulare del responsabile sono raggruppati nel gruppo numero di telefono 43

44 Figura 27: L'operazione di creazione di un nuovo campo chiede inizialmente alcune informazioni basilari. A questo punto è possibile inserire tutti i campi necessari per il proprio Custom Content Type. Nel caso del portale Energy CHIT la tabella utenti è così fatta: Figura 28: Campi della tabella Utenti Energy CH-IT Con una buona dose di pazienza si inseriscono tutti i campi in Drupal impostando per ogni campo i parametri richiesti e quelli opzionali a seconda del caso; fra i più rilevanti: Il tipo primitivo del dato (testo, intero, binario, oat.. cc); Il tipo di Input Field (Casella di testo, Checkbox,Text Area,ecc); La lunghezza massima dell'input; L'opzione not null, praticamente un campo obbligatorio. Alla ne della procedura si ottiene una schermata come in gura sotto. 44

45 Figura 29: Elenco dei campi al termine della procedura di inserimento Come si può notare i campi sono stati ordinati come da prototipo della tabella. L'unico vincolo che pone il modulo CCK è che venga inserito obbligatoriamente il campo di default 'Titolo', esso viene utilizzato come chiave primaria per ogni tupla della tabella. Se non è già presente nel le.xls da importare basta semplicemente aggiungere una colonna in testa al le, nominarla 'Titolo' e inserire come valori numeri interi incrementati di uno partendo da zero. A questo punto l'operazione di creazione di un Custom Content Type è terminata e si può procedere all'utilizzo del modulo 'Node Import'. 4.4 Modulo Node Import, utilizzo pratico Come già detto nella sottosezione 4.2.2, si accede alla schermata del modulo e ci si posiziona nel tab 'New Import' per iniziare l'operazione di Import. L'operazione è stata realizzata mediante un wizard di otto passi in cui si andranno a congurare tutte le opzioni per ottenere il risultato voluto. Analizzeremo in questa sezione tutti gli 8 passi anche se alcuni sono piuttosto immediati da svolgere Passo 1: Selezione del Content Type In questo primo 'step' viene richiesto di indicare il tipo di dato compatibile con i dati da importare, nel nostro caso l' EnergyCHITUsers appena creato Passo 2: Selezione del le da importare Il secondo passo richiede si selezionare il le contenente i dati da Importare. Il File, come da speciche, può avere estensione.csv o.tsv; nel nostro caso andremo ad importare un le.csv. Il le.csv, come detto in precedenza, è facilmente ottenibile dal le.xsl salvando l'ultimo nell'estensione voluta tramite 45

46 qualsiasi editor di fogli di calcolo; inoltre, una volta convertito il le, è necessario controllarlo per vericare che la conversione non abbia provocato errori di sintassi e che sia correttamente formattato secondo le speciche del formato.csv. Una volta prese queste accortezze si può procedere al passo successivo. Figura 30: Passo numero 2 per la fase di import: La selezione del le contenente i dati Passo 3: Impostazioni del le da importare Il terzo passo è un 'settings step' dove si specica come è stato formattato il le.csv. La prima cosa da aggare è l'opzione che indica che la prima riga del le contiene il nome degli attributi; questa opzione è facoltativa ma è buona norma selezionarla sempre per facilitare Drupal a mappare gli attributi indicati sui campi della struttura dati creata con il CCK. Il resto di questo passo consiste nel scegliere la formattazione adottata nel le.csv. Il le convertito degli utenti del portale Energy CHIT è cosi formattato: File Format: Semicolon Separated Value ( non si riferisce all'estensione pura del le ma ad alcune varianti della formattazione del le CSV); Record Separator : NewLine, cioè il classico carattere di 'a capo'; Field Separator: il carattere che separa i campi ( ; ); Text Delimiter e Escape Character: il carattere (); Alla ne della pagina viene inoltre mostrato un esempio del le caricato nel passo 2 per facilitare la scelta della formattazione. Dopo aver correttamente scelto l'opzione giusta si può procedere al passo successivo. 46

47 Figura 31: Passo 3: Settaggio delle opzioni di formattazione del le Passo 4: Mappatura degli attributi del le con i campi della struttura dati Questo 4 passo è denibile 'gratis', poiché non c'è nulla da fare. Se il le.csv alla prima riga contiene i nomi degli attributi, e questi nomi sono esattamente uguali ai campi della struttura customizzata, il mapping lo fa Drupal stesso senza chiedere nulla in aggiunta. In fondo alla schermata inoltre Drupal fa un esempio tabellare praticamente uguale al le.xsl di origine ( solo con 4/5 tuple) per far comprendere visivamente che no a questo punto va tutto bene. Oltre alla mappatura dei campi sono presenti altre voci per le opzioni di pubblicazione, sono opzionali e non inuiscono sull'esito dell'import. Dopo aver controllato l'esatta mappatura si può procedere tranquillamente al passo numero Passo 5: Opzioni per l'importazione Questo passo invece, è piuttosto oscuro, con tutte le prove di import svolte non è mai stato richiesto nulla da impostare o altro; si rivela ancora più 'gratis' del passo numero Passo 6: Impostazione dei valori di default In questo terzultimo passo il wizard richiede alcune informazioni di default da allegare all'import quali Il formato dell'import, Filtered o Full HTML ( il le.csv è solitamente ltered poiché contiene solo dati senza neanche una riga di HTML); Informazioni riguardanti l'autore dell'import; Informazioni sulla revisione; 47

48 Opzioni di pubblicazione (diverse da quelle presenti nel passo 4); Impostazioni sulle opzioni per inserire dei commenti sull'import; Passo 7: Anteprima dei dati Nel settimo passo, Drupal dovrebbe mostrare l'anteprima dei dati prima dell'import nale. Uso il condizionale poiché dalla prima no all'ennesima prova, il sistema ha dato sempre e solo Warning. Figura 32: Passo 7: Il problema dei Warning sull'anteprima dell'import Inizialmente questi 'pericoli' sono stati ignorati proprio per il loro senso intrinseco, cioè non segnalano errori ma avvertono di potenziali problemi. Tuttavia in seguito questi warning trascurati saranno fondamentali per l'esito del progetto; andremo ad analizzare questo problema successivamente non appena sarà nita la descrizione del wizard di import. 48

49 4.4.8 Passo 8: Inizio dell'import L'ultimo passo consiste in un riepilogo delle informazioni principali ottenute in tutti i passi precedenti, dando all'utilizzatore, una visione complessiva del lavoro svolto durante il wizard. Figura 33: Ultimo passo: Visualizzazione di riepilogo prima di iniziare l'import Figura 34: Seconda schermata che riassume le informazioni nel passo 8 Inne dando il comando 'start import' il processo viene eseguito; al termine una pagina compone il risultato dell'operazione fornendo alcune informazioni sul risultato, quali: 49

50 Il risultato dell'operazione; Il numero di righe importate; Il numero di righe importate con errori (zero signica che tutto è andato liscio); Informazioni sul processo di import (data e ora, utente loggato che ha eettuato l'import, e il nome del le importato). Inoltre è possibile fare interrogazioni sulla tabella di Drupal appena popolata per identicare: Le righe con errori; Le righe senza errori; Tutte le righe con l'aggiunta dell'eventuale codice di errore; Tutte le righe con la chiave primaria in testa alla tupla. Se si richiedono queste interrogazioni il risultato è un le.csv scaricabile contente le tuple che hanno avuto riscontro. Figura 35: Risultato dell'operazione di import con annesse funzioni di interrogazione I risultati di tutti i test di import hanno mostrato sempre un esito apparentemente positivo; tutte le righe vengono importate senza errori e anche gli Id vengono importati correttamente. Tuttavia i primi problemi si sono vericati quando è sorta la necessità di interrogare la tabella contenente gli utenti del portale Energy CHIT. Prima di arontare il problema riscontrato è necessario svolgere un'attività riassuntiva su come si eseguono interrogazioni tramite le Viste. 50

51 4.5 Creazione di interrogazioni sul database tramite le Viste Le viste sono, come accennato nella sezione di introduzione, uno dei concetti fondamentali per un CMS. Nel caso di Drupal sono l'unico strumento per accedere ai contenuti immagazzinati nel database. Il modulo 'viste' non è preinstallato nella versione di default ma è presente come contenuto extra scaricabile. L'importanza di questo strumento è accentuata anche dai numerosi plugin sviluppati dalla comunità Drupal che arricchiscono le funzioni già presenti (Views Node Feed, Views Importer, Views Datasource, ecc.). Dopo aver installato il modulo, e dopo aver aggiunto eventuali plugin necessari, l'interfaccia di creazione delle viste è raggiungibile dalla sezione di amministrazione del sito e si presenta come mostrato in gura sotto. Figura 36: Pagina principale del modulo Viste Le opzioni di navigazione permettono di: Mostrare l'elenco delle viste create e delle viste di default, modicarle ed esportarle; Aggiungere una nuova vista; Importare viste precedentemente esportate (se si ha attivato il modulo relativo); Raggiungere un pagina 'tools', cioè strumenti che permettono di abilitare una serie di opzioni sulle viste; non vengono analizzate poiché sono nominate in modo autoesplicativo e posseggono inoltre un ulteriore descrizione sul loro ruolo. La funzione principale è ovviamente quella che crea nuove viste, l'andremo immediatamente ad analizzare. 51

52 Non appena entriamo nella sezione, il sistema richiede alcune informazioni iniziali (nome, descrizione e che tipo di dato si vuole estrarre); nel caso che si voglia estrarre il contenuto di una custom structure l'opzione da scegliere è 'nodo', negli altri casi invece si possono scegliere le strutture di default. La fase successiva (mostrata sotto) è il cuore della creazione delle viste; qui si possono impostare una serie notevole di parametri per poter comporre la Query. Figura 37: Il 'core' della creazione delle viste. Il procedimento è composto da 3 blocchi principali disposti da sinistra verso destra: Il primo blocco riguarda Pagine e Blocchi, serve per denire come la vista deve essere visualizzata, se come blocco o come pagina. In questa si sceglie se si vuol creare una nuova pagina (o blocco), l'url, il tipo di vista da visualizzare (vale a dire se nella vista i contenuti devono essere visualizzati per intero o solo come un'anteprima, in una tabella, ecc.), l'intestazione, il footer, il menù, se si vuole utilizzare ajax e tanto altro ancora. Un parametro importante da evidenziare è il path, esso serve per impostare il percorso della vista raggiungibile direttamente dall'url (es: in questo modo si inizia già a denire una gerarchia di pagine all'interno del sito. Inoltre è possibile posizionare la raggiungibilità della vista in un qualche menù di navigazione presente nel sito (basta specicare il nome del menù ed essa sarà aggiunta automaticamente). Il secondo blocco riguarda più un aspetto 'tecnico', si posso impostare eventuali relazioni (cammini di join), argomenti (i parametri che si mettono nella condizione 'where') e i campi da visualizzare che sono praticamente i campi che vengono inseriti nella 'select'. Gli argomenti vengono passati a Drupal tramite l'url, questo sfrutta esattamente il metodo 'get' che viene nascosto all'utilizzatore all'interno del codice del modulo. 52

53 Il terzo blocco riguarda i criteri di ordinamento e i ltri; la sezione ltri serve per ltrare quale tipo di contenuto (nodo, tassonomia... ) vogliamo visualizzare (es. Tipo di contenuto-> Story, visualizzerà solo i contenuti di tipo Story). Nella sezione criteri di ordinamento si può settare l'ordine di visualizzazione della vista (es. ordinati per data). Un esempio pratico potrebbe essere quello di visualizzare in una Pagina il contenuto della tabella Utenti di Drupal, estraendo il nome, l' e la data di registrazione. Risulta necessario specicare un piccolo ma signicativo concetto: nel caso si voglia estrarre dati da una sola tabella, il tool, nei suoi settings, non permette di impostare il nome della tabella. Quindi come si fa?. La risposta è piuttosto semplice ma altrettanto non immediata da comprendere; Drupal non vuole fare vedere l'elenco delle sue tabelle, poiché possiede una metodologia di organizzazione delle tabelle tutta sua e abbastanza dicile da comprendere, perciò applica una procedura piuttosto intelligente per fare la select sulla tabella giusta: 1. In base al tipo di dato selezionato nella pagina iniziale della procedura di creazione, ltra le tabelle non necessarie; 2. Dopo questa 'scrematura' applica una procedura per vericare i permessi ( si ricorda che l'utente può interrogare solo le tabelle di cui è proprietario e quelle di default). Con questo sistema elimina ulteriori tabelle del tipo di dato corretto ma che non sono accessibili. 3. Le rimanenti tabelle sono quelle che contengono le informazioni accessibile e desiderate. Ora la domanda sorge spontanea: Se ci sono due tabelle Utenti per esempio, di cui una contiene gli utenti attivi e l'altra quelli non attivi, e voglio estrarre il nome di quelli attivi, come faccio a distinguere il campo 'nome' di quelli attivi e non attivi? Risposta> Quando seleziono i campi da visualizzare, i campi sono disposti secondo la sintassi [Nome Tabella: Nome campo], in questo modo Drupal elimina le ambiguità fra nomi di campi uguali. Le viste sono utilissime per popolare il proprio sito di contenuti personalizzabili ma, a dierenza degli altri strumenti di drupal, non sono immediate da padroneggiare. Come detto in precedenza, le viste, posseggono una lacuna sulla possibilità di eettuare interrogazioni complesse (es. Query concatenate); per questo motivo è stato sviluppato un plugin (Custom Reports) e si rimanda alla sezione dei moduli di Import/Export per comprenderne il funzionamento. 53

54 4.6 Problemi riscontrati con l'operazione di migrazione del database All'inizio dei test con il modulo 'node import' gli unici errori riscontrati furono i vari warning che, nel 7 passo, indicavano dei problemi sulla visualizzazione dell'anteprima dell'import. I problemi reali sono sopraggiunti quando sono passato alla realizzazione della vista per mostrare i contenuti appena importati. La vista o query in questione è piuttosto semplice, una banale selezione di tutti i campi nella tabella EnergyCHITUsers ordinati per chiave primaria. La costruzione e l'esecuzione di tale interrogazione è stata necessaria per provare che l'operazione di import era andata a buon ne, nonostante che il modulo incaricato avesse dato esito positivo. Il problema, tradotto in risultato, è che la query non restituiva nulla come risultato. Di primo impatto ho pensato che avessi sbagliato l'impostazione della query e dopo una serie ripetuta di test questa opzione è stata scartata poiché la vista era giusta. Dopo un certo numero di riessioni ho deciso di scendere di livello ed entrare nel sistema di gestione del database di Drupal. Figura 38: Pagina di Amministrazione 'manuale' del database di Drupal Il mio intento era quello di esplorare le tabelle del modulo 'node import' per vericare che esse fossero state popolate dall'operazione di importazione. Come da speciche il database di Drupal è piuttosto grande e poco chiaro; il CMS, appena installato, crea già una trentina di tabelle in cui gestisce i suo contenuti privati. Inoltre ogni modulo installato e attivato crea una o più tabelle dove va a inserire i dati più svariati; ma secondo la logica di Drupal, l'utilizzatore non dovrebbe mai entrare in questa sezione, e quindi non è un obbiettivo rendere il database leggibile e comprensibile nella sua versione 'nuda'. 54

55 La ricerca delle tabelle create dal modulo è stata abbastanza semplice poiché, a dispetto del contesto, il nome di ogni tabella è abbastanza chiaro e riconduce immediatamente al modulo proprietario. Figura 39: Le tabelle del modulo node import Come mostrato in gura sopra le tabelle create dal modulo 'node import' sono 2: node_import_status; node_import_tasks; La prima contiene tutti i dati importati, in cui ogni tupla è un record completo; mentre nella seconda sono memorizzate tutte le operazioni di import eettuate (quest'ultima tabella è stata ripulita poiché le prove di import non sono state molte più di una). Il fattore evidente è che la tabella 'import_status' contiene 60 tuple e il le 'utenti_energy_chit.csv' contiene esattamente 60 record, ciò dimostra che l'operazione di import ha prodotto 'qualcosa'. Il contenuto è stato denito 'qualcosa' perché se si entra nella tabella in modalità 'mostra contenuto' il risultato non è per nulla chiaro (vedi gura sotto). 55