L’organizzazione dell’evento è stata precisa e amichevole, e ho potuto conoscere alcune persone piacevoli. L’evento in sé, magari, forse non era necessario chiamarlo “barcamp”, visto che comunque prevedeva non solo un’organizzazione dei talk precedente all’evento stesso, ma addirittura una selezione degli stessi basata sulla votazione dei partecipanti sul sito, votazione che si è conclusa una settimana prima dell’evento. Niente di male, per carità, ma non è che ci sia niente di male nelle parole “seminario” o “conferenza” :)

Io ho potuto presentare un talk sull’integrazione di Drupal con SOLR e sono felice di aver ottenuto anche un discreto successo di pubblico e di critica, come si suol dire :)

La parte più interessante è stata la tavola rotonda finale che aveva come argomento (ovviamente) il rilascio prossimo venturo della versione 7 del CMS. Questa è stata la parte più propriamente “barcamp” di tutto l’evento, dove per ogni slide presentata da uno dei partecipanti si accendeva una discussione tra tutti gli altri seduti ad ascoltare che, appunto, diventavano partecipanti :)

A proposito di Drupal 7:

• si sperava in un regalo di natale, ma prima di febbraio/marzo non se ne parla
• 50 tra i moduli più usati hanno fatto la “promessa” di preparare la versione per D7 non appena questo uscirà (pare ne manchino ancora 3 o 4 all’appello)
• D7 è più lento da un minimo del 20% ad un massimo del 50% rispetto a D6. È opinione comune che questo sia un problema dovuto al nuovo “db layer” basato su PDO
• il creatore di Views pare sia un po’ in rotta con Dries, e questo fa sì che quel (ormai fondamentale) modulo sia in ritardo…

Questo problema ha più soluzioni, ecco la mia (che prevede, per semplicità, di avere il sistema di test sulla propria macchina in localhost).

Necessario:

• Un’installazione di Drupal (e fin qui…)
• Modulo Drupal SMTP
• Lo script fakemail (disponibile sia in Perl che in Python)

Fakemail è un programmillo che in pratica simula un server SMTP; rimane in ascolto su una porta scelta a piacere e salva le email che gli vengono spedite come file dentro una directory anch’essa scelta a piacere.

Il modulo SMTP di Drupal, invece, permette di scegliere attraverso quale sistema SMTP Drupal debba spedire le email; si possono scegliere l’hostname del server, la porta ed evntualmente anche l’autenticazione. Queste stesse cose possono essere fatte a “livello di configurazione PHP”, ma in questo modo è ovvio che la configurazione rimane più trasparente.

Seguendo le istruzioni installate ed eseguite lo script fakemail. Fate in modo che questo ascolti su una porta alta, diciamo la 10025. Fate anche in modo che il path nel quale le email vengono salvate sia visibile dall’installazione Drupal (o comunque dal vostro web server). All’interno di questa directory create un .htaccess dove scriverete un’unica riga: options +indexes.

Configurate il modulo SMTP in modo che sia attivo ed utilizzi “localhost” come server e la porta 10025.

A questo punto provate a spedire una email con Drupal (per esempio, potete usare la form di recupero password) e poi puntate il browser alla directory di cui sopra; la vostra email apparirà come fosse un qualsiasi file che potrete aprire per vedere cosa vi sarebbe stato spedito.

Nota bene: questo sistema ovviamente NON funzionerà se il modulo che state provando NON utilizza la “drupal way” per spedire email ed userà invece direttamente la funzione mail() del PHP. Per modificare il comportamento di questa occorrebbe allora agire a livello di configurazione del PHP impostando la variabile di configurazione “sendmail_path”.

Drupal, come tutti i progetti grossotti, fa esteso uso del tagging nel suo repository. Tutto sta dunque a capire quale sia il “tag” corrispondente alla versione 7 di Drupal. In questo caso è molto semplice, visto che il tag è HEAD (ovvero il branch di sviluppo). Fare il checkout con CVS è questione di eseguire il seguente comando nella directory dove si vuole venga creata la sottodirectory con drupal stesso (per esempio, public_html)

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -r HEAD drupal

Pochi secondi dopo avrete il vostro Drupal 7 nella directory “drupal”. Successivamente, per vedere se ci sono aggiornamenti, sarà sufficiente entrare in quella directory ed eseguire

cvs up

Sarà opportuno eseguire, subito dopo il cvs up, anche un update.php per aggiornare eventualmente tabelle del database.

Gli step di installazione sono gli stessi di Drupal 6; dunque occorre:

• creare un database (Drupal 7 supporta out of the box anche sqlite, volendo)
• copiare sites/all/default.settings.php in sites/all/settings.php e dargli provvisoriamente un bel chmod 666 per fare in modo che l’installer lo possa aggiornare
• andare con un browser sul nuovo sito

Vi verrà chiesto in che lingua installare e, successivamente, quale profilo. Anche questa seconda opzione è una novità: avrete la possibilità di scegliere un profilo “standard”, ovvero molto scarno, oppure un profilo un pochino più avanzato nel quale, per esempio, viene creato automenticamente il vocabolario “Tags” associato ai due tipi di documento di default.

Girovagando tra le opzioni, non mi è sembrato di vedere nessuna grossa novità. Mi è saltata all’occhio soltanto l’aggiunta di una descrizione ai permessi. Hanno anche rinominato “Story” in “Article”.

Naturalmente non andate a cercare, per ora, la traduzione italiana.