Stato documento: Alfa

Vedi anche Creazione di un modulo (incompleto), e Creazione di un modulo Drupal (Tutorial) (più esteso).

Qualche volta vediamo piccoli pezzi di codice utile, con il consiglio di metterlo nel nostro modulo custom. Ma come si fa a creare un modulo custom? E che cos'è un modulo custom?

Un modulo custom è un modulo scritto appositamente per un singolo sito. Non si trova su http://drupal.org, e semplicamente qualcosa che è tutto nostro - e quindi anche di nostra responsibilità.

Moduli esterno al core di Drupal vengono inseriti in sites/all/modules, ma niente ci vieta a mettere un modulo in un sotto indirizzario di questo. Da "Pro Drupal Development", viene suggerito di mettere moduli custom in sites/all/modules/custom, per tenerlo 'distante' dai moduli scaricati da http://drupal.org.

Come minimo dovremo creare due file, ma prima bisogna 'inventare' un nome per il nostro modulo custom. Il nome del sito può andare bene, ma ricorda che il nome può contenere solo lettere non accentati, e che viene usato come prefisso per tanti funzioni - quindi la brevità aiuta. Se il sito forse http://drupalitalia.org, possiamo usare drupalitalia o forse di come nome più breve. Basta che è sufficientemente originale da non fare conflitto con nomi di moduli già esistente.
Metteremo questi due file in un indirizzario sites/all/modules/drupalitalia, per esempio.

Regola #1 A questo punto in poi dove vedi custom in questo documento bisogna sostituire il nome che hai scelto - drupalitalia per esempio.

Il primo file viene letto da Drupal per capire cosa fa il modulo, senza caricare codice, e si chiama custom.info. Il suo contenuto minimo è molto semplice:

Il secondo file contiene il codice che aggiungiamo dopo, e si chiama custom.module. Il suo contenuto minimo è ancora più semplice:

• Togliendo il ?> si elimina la possibilità di indesiderati spazi bianchi alla fine dei files che posso causare gli errori di "header already sent", problemi di validazione XHTML/XML, e altri problemi.
• Il delimitatore di chiusura alla fine del file è opzionale.
• Lo stesso PHP.net rimuove il delimitatore di chiusura dalla fine dei suoi files (esempio: prepend.inc), questa prassi viene identificata come il modo migliore di scrivere codice PHP per Drupal.

A questo punto possiamo attivarlo. Nota: il modulo si trova sotto 'Altro'. Per il momento non sta faccendo niente. Ma quanto lo fa bene - e senza errori!

Adesso aggiungiamo un pò di codice. Questi pocchi righe fanno che non si può disattivare il modulo dalla pagina admin/build/modules/list - una precauzione che trovo utile. In custom.module, aggiungiamo in fondo:

Ma dobbiamo anche fare sapere a Drupal di questi modifiche, prima che viene eseguito questo nuovo codice (da "Letting Drupal know about the new function"): vai in admin/settings/performance, in fondo alla pagina clicca 'Eliminare i dati della cache'.

Se adesso torni a admin/build/modules/list troverai che il nostro modulo custom non può essere disattivato.

Nota: Se vuoi aggiungere altre codice alla funzione custom_form_alter bisogna aggiungerlo dentro la funzione stesso - non puoi avere due funzioni chiamati custom_form_alter, pena un bel messaggio in rosso di errore da PHP.

Nota: I file allegati finiscono con .txt o _.txt, se voi provarli sul tuo sistema bisogna rimuovere quest'ultimi. I nomi giusti sono drupalitalia.info e drupalitalia.module.

Introduzione (EN): http://drupal.org/node/292

Maggiori info per i moduli (EN): http://drupal.org/node/231276

Info in inglese: http://drupal.org/node/301181

In questa pagina sono elencati una serie di suggerimenti ai traduttori, con lo scopo di ottenere una traduzione il più possibile coerente.

E' benvenuta qualsiasi discussione riguardo a possibili nuove traduzioni, interpretazioni o modi di tradurre. Il forum dove discutere è il Gruppo Traduzioni.

Costruzione delle frasi:

• Nelle frasi destinate agli utenti e agli amministratori del sito, evitare il più possibile di tradurre you come tu

Esempio: welcome to your new Drupal installation => benvenuto nella nuova installazione di Drupal
Sono tipiche costruzioni dell'inglese e in italiano non rendono bene.

• Mantenere i termini più vicini possibile all'originale, dove non perdano di senso.

Esempio: authentication = autenticazione

• Cercare di ottenere frasi più brevi possibili, purché non perdano di senso.
• La maggior parte dei termini inglesi hanno degli equivalenti italiani (vedi sotto). Alcuni termini, tuttavia, sono termini strettamente tecnici, quindi è opportuno evitare di tradurli.

Esempio: browser, download, log, ping.

• Mantenere una traduzione professionale, evitando "neologismi" come "pingare", "bannare", etc.

Dove necessario, fare una perifrasi.
Esempio: ping server = esegui ping del server

Frasi tipiche

Accenti

Gli accenti vanno in UTF-8. Possibilmente anche quelli maiuscoli. è,è,à,ò,ì,ù e non e',a',o',i',u'.

Maiuscoli: É, È, À, Á, Ì, Í, Ò, Ó, Ù, Ú

Tag HTML

Correggere i tag HTML in XHTML 1.0 se sbagliati.

diventerà
diventerà

Nomi dei moduli

Quando i vocaboli indicano il nome del modulo, per distinguerli dalle traduzioni si è deciso di tenere il nome in inglese, tra apici, sempre minuscolo:

Esempio:
book module = modulo 'book'
Book module = modulo 'book'
update book module = aggiorna il modulo 'book'

Vocaboli suggeriti

Guarda il glossario dei termini.
http://www.drupalitalia.org/glossary

Termini su cui discutere:
Top, Directory, Toolbar, Font, Plugin, Maintain, Authored, Match, Denied, Allowed, Token, Toggle

In questa pagina sono elencati una serie di suggerimenti ai traduttori, con lo scopo di ottenere una traduzione il più possibile coerente.

E' benvenuta qualsiasi discussione riguardo a possibili nuove traduzioni, interpretazioni o modi di tradurre. Il forum dove discutere è il Gruppo Traduzioni.

Costruzione delle frasi

• Nelle frasi destinate agli utenti e agli amministratori del sito, evitare il più possibile di tradurre you come tu

Esempio: welcome to your new Drupal installation => benvenuto nella nuova installazione di Drupal
Sono tipiche costruzioni dell'inglese e in italiano non rendono bene.

• Mantenere i termini più vicini possibile all'originale, dove non perdano di senso.

Esempio: authentication = autenticazione

• Cercare di ottenere frasi più brevi possibili, purché non perdano di senso.
• La maggior parte dei termini inglesi hanno degli equivalenti italiani (vedi sotto). Alcuni termini, tuttavia, sono termini strettamente tecnici, quindi è opportuno evitare di tradurli.

Esempio: browser, download, log, ping (altri esempi sono presenti nel glossario http://www.drupalitalia.org/glossary).

• Mantenere una traduzione professionale, evitando "neologismi" come "pingare", "bannare", etc.

Dove necessario, fare una perifrasi.
Esempio: ping server = eseguire ping del server

• Dove possibile, nelle frasi volitive (es. invito a fare clic su un pulsante, a salvare un contenuto, ecc.), usare il modo infinito in modo impersonale.
  Esempio: save content = salvare il contenuto

Accenti

• Gli accenti vanno inseriti in UTF-8, senza usare gli apici al loro posto. è,è,à,ò,ì,ù e non e',a',o',i',u'.
• Usare anche gli accenti maiuscoli: É, È, À, Á, Ì, Í, Ò, Ó, Ù, Ú
  Per inserire maiuscole accentate su Mac:
  Accento acuto: option-8, seguito dalla lettera (es. option-8 E)
  Accento grave: option-9, seguito dalla lettera (es. option-9 A)

Tag HTML

• Copiare correttamente l'uso dei tag HTML, se presenti. Se ci sono errori nell'uso dell'HTML della stringa originale, segnalare la cosa aprendo una issue su drupal.org.

Nomi dei moduli

• I nomi dei moduli non vanno tradotti e vanno lasciati con la maiuscola iniziale. (NB: rispetto alle traduzioni di Drupal 6, non vengono più usati gli apici)
  Esempio: Book module = modulo Book

Nomi delle pagine di amministrazione

• Spesso nei testi di aiuto da tradurre le pagine di amministrazione vengono citate come "…using the Block administration page". La traduzione corretta non è "…usando la Pagina di amministrazione dei blocchi", ma "…usando la pagina di amministrazione Blocchi". I titoli delle pagine di amministrazione, infatti, vanno tradotti e sono nomi propri.

Vocaboli suggeriti
Guarda il glossario dei termini, per mantenere la coerenza delle traduzioni.
http://www.drupalitalia.org/glossary

Termini su cui discutere
Toggle

Avete deciso di tradurre un modulo (base o aggiuntivo) potete usare il nuovissimo server di traduzione online qui su Drupal Italia, oppure tradurla autonomamente sul vostro computer.

Se decidete di usare il server di traduzione (l10n server), leggete la guida su come usarlo e come utilizzare le traduzioni. Altrimenti se volete tradurre autonomamente, senza usare strumenti di condivisione avete bisogno di due cose:

• un template di traduzione del modulo
• il programma di traduzione

Il template non è altro che un file di testo contenente tutte le frasi che compaiono (in inglese) nel modulo. Drupal utilizza per le traduzioni il formato .po di Gnu GetText: si tratta in pratica di un file di testo che contiene la frase originale, la frase tradotta corrispondente più alcune informazioni aggiuntive (p.e. come gestire i plurali, etc). I template (cioé l'insieme delle frasi da tradurre) ha di solito l'estensione .pot (da cambiare in .po dopo la traduzione.
Possono presentarsi due situazioni:

• il template esiste già, perché messo a disposizione dal realizzatore del modulo o perché esiste già una traduzione in un'altra lingua. Per esempio, i template di tutti i moduli di base (del core) sono disponibili qui.

Attenzione perché spesso le traduzioni in altre lingue non sono aggiornate. E' quindi sempre consigliabile seguire il punto 2, cioè creare un nuovo template di traduzione tramite il modulo POTX.

• il template non è disponibile, e quindi andrà creato. Per ovviare a questo, usate il modulo POTX.

  Andate su localizzazione e su manage strings. Selezionate il modulo e premete extract. Se un pacchetto modulo, comprende più file .module, estraete tutte le stringhe in un solo file pot. L'opzione la trovate proprio sopra il link a scomparsa.
  Potrete così scaricare il file .pot da iniziare a tradurre.

Descrivo qua come ho affrontato il problema della registrazione sul portale che sto realizzando.
Si richiedeva potessero registrarsi due tipologie di utenti:

• persona (privato cittadino, ecc.),
• responsabile aziendale.

A seconda della scelta effettuata i campi da completare sarebbero risultati diversi. In particolare, con la seconda scelta, oltre ai campi per il profilo si doveva poter inserire sul portale l'azienda che l'utente rappresenta (e questa dovrà poi essere indicizzata per la ricerca).
L'utente (a qualunque profilo appartenga) doveva essere immediatamente loggato, visibile e con tutte le funzionalità; mentre l'eventuale azienda da questi inserita poteva essere visibile solo in seguito ad approvazione dalla redazione/amministrazione.

Sono stati dunque creati i seguenti ruoli per distinguere questi profili:

• Azienda,
• PreAutenticazione.

Moduli usati
I moduli utilizzati per raggiungere lo scopo sono stati:

• Email Registration: usato per registrarsi e loggarsi con una email al posto di un nome utente. Lo username viene generato a partire dalla parte dell'email che precede la @. In caso due utenti abbiano lo stesso prefisso dell'email, il sistema assegna un numero progressivo. Lo username può comunque essere reso modificabile. Per farlo:
  Gestione utente > Permessi e assegnare il permesso "cambia il suo nome utente" all'utente autenticato,
• Login Toboggan: grazie a questo modulo l'utente sceglie la password in fase di registrazione (non gli arriva per mail) e si trova loggato, apparentemente con tutti i diritti di un utente autenticato. In realtà se non convalida la propria mail (rispondendo alla stessa) entro un certo numero di giorni il suo account viene eliminato,
• Auto Assign Role: permette all'utente di scegliere il proprio ruolo al momento della creazione dell'account,
• Automatic Nodetitles: nasconde il campo titolo in fase di inserimento di un contenuto usando i token per riempirlo automaticamente,
• Content Profile: Fondamentale! Usato per trattare i profili come fossero tipi di contenuto (o nodi) e avere quindi tutte le potenzialità di CCK. Inoltre fornisce la possibilità di associare profili diversi a ruoli diversi,
• Content Profile User Registration: per rendere disponibili i content profile già in fase di registrazione utente.

Procedura
Passi da seguire:

1. Installare ed abilitare i moduli appena elencati.
2. Gestione utente > Impostazioni utente e selezionare l'opzione "I visitatori possono creare profili e nessuna approvazione degli amministratori è richiesta". In questo modo l'utente può scegliersi direttamente la password in fase di registrazione e si trova loggato prima di dover rispondere all'email. D'altra parte potrebbe avere inserito una mail falsa o scorretta e per ovviare a questo problema si usa il modulo Login Toboggan. Sostituire anche l'email di \textit{Benvenuto} con:
   !username,</li>
grazie per esserti registrato su !site.
Puoi ora effettuare l'accesso su !login_uri usando i seguenti nome utente e password:
nome utente: !mailto
password: !password
È importante che confermi la correttezza dell'email facendo clic su questo link:
!login_url
SE NON LA AUTENTICHERAI IL TUO UTENTE SARÀ CANCELLATA ENTRO UNA SETTIMANA!
--  Lo staff di !site

3. Come detto, con questi passaggi si permette all'utente di essere subito loggato senza dover rispondere alla email. Per questo si suggerisce un ruolo cosiddetto "PreAutenticato" ("This will allow users to choose their initial password when registering. If selected, users will be assigned to the role below (PreAutenticazione appunto). They will not be assigned to the 'authenticated user' role until they confirm their e-mail address by following the link in their registration e-mail. Esiste, inoltre, un'opzione (sempre nella pagina delle impostazioni del modulo) per eliminare gli utenti che non confermano l'email entro un certo numero di giorni.
4. Creare quella che si vorrà usare come pagina di disambiguazione per scegliere con quale ruolo e profilo registrarsi sul portale (privato o aziendale). Il tipo di contenuto sarà Pagina e il contenuto sarà qualcosa tipo:
<strong>Pagina di registrazione (con scelta)</strong>
Scegli se vuoi registrarti come
<a href=user/register/profilepriv>PRIVATO</a>
oppure come
<a href=user/register/profileaz>AZIENDA</a>
5. Nelle "Impostazioni percorso URL" togliere l'Automatic Alias e impostare a mano un percorso di primo livello (registrazione è un buon esempio, non lo è content/registrazione). Questo per non creare conflitti successivamente con Auto Assign Role.
6. Dopo aver abilitato il modulo Content Profile si trova un nuovo tipo di contenuto Profile. Modificarlo come se fosse il Profilo di un utente privato. In particolare, noi ci troviamo nella situazione di avere due profili leggermente diversi per privato e responsabile aziendale (quest'ultimo dovrà ad esempio specificare anche il ruolo in azienda, un telefono o fax) e per questo creeremo due diversi tipi di contenuto Profilo Privato e Profilo Aziendale.
   Per questi due tipi di nodo che si vogliono usare come profilo si deve spuntare in fondo alla pagina del tipo di contenuto la voce: "Use this content type as a content profile for users". Solo in questo momento nella pagina compare una nuova scheda "Content Profile".
7. Bisogna assegnare all'utente la possibilità di editare il proprio profilo e quindi in Permessi aggiungere per l'utente autenticato "edit own profile content". Inoltre, al momento della creazione profilo (quindi prima che l'utente sia autenticato) l'utente deve essere messo in condizione di poter modificare i campi del profilo e quindi i permessi di edit sui field del profilo vanno attribuiti anche agli utenti anonimi. Questa dunque è la parte più delicata; settare i permessi relativamente ai tipi di contenuto che dovranno gestire i vari ruoli.

   Quote:

   Suggerimento:
   Con il modulo Automatic Nodetitles si nasconde il campo titolo in una form.
   Il campo titolo è quello usato anche nell'url di quel nodo.
   Questo viene generato automaticamente a partire da un dato pattern.
   In ogni tipo di contenuto si trova, dopo aver abilitato questo modulo, una sezione "Automatic title generation"
   dove si può scegliere "Automatically generate the title and hide the title field".
   Per scegliere come generarlo si può scorrere la lista dei token disponibili (http://drupal.org/node/390482).

8. Gestione Utente > Auto assign role > Assign from Path in User Register Node si inserisce la pagina che si vuole usare per sostituire la user/register. Mettere qui il nodo di tipo Pagina creato al punto 4. Per ognuno dei ruoli che si intende usare spuntare "Attivato". Come metodo "Pages with no navigation" ed inserire path diversi a ruoli diversi (ad esempio user/register/profilepriv e user/register/profileaz).
9. Tornare nelle pagine dei tipi di contenuto nel tab Content Profile. La prima parte delle configurazioni è relativa a come vengono visualizzati i profili. Nella sezione User Registration aggiunta grazie al modulo Content Profile User Registration mettere le due spunte per usare i profili in fase di registrazione utente.
   In Use on Auto Assign Role paths lasciare la spunta solo sul ruolo desiderato, quindi su "(PreAutenticazione) user/register/profile" dal tipo di contenuto Profilo Privato e "(Azienda) user/register/ecocompany" dal tipo di contenuto Profilo Aziendale, ma anche dal tipo di contenuto Azienda.
10. Ricontrollare i permessi assegnati ai ruoli in gioco in modo da evitare che un profilo possa modificare campi e contenuti che non gli competono.
11. Per finire, in Costruzione del Sito > Temi > Configura > Impostazioni globali c'è la voce Mostra le informazioni del contenuto su e lì si toglie la spunta da tutti i tipi di contenuto nei quali non voglio venga visualizzata la scritta "Inserito da ... il ...".

Due moduli che potrebbero essere interessanti in questo contesto sono anche PageRoute e Real Name. Putroppo il primo non l'ho usato perché non sono riuscito a capire come integrarlo con quanto fatto, anzi non sono proprio riuscito a capire se sia compatibile con la fase di registrazione (lo era con Drupal 5 e il modulo Node Profile, ma sono portato a dire che da Drupal 6 Pageroute non sia utilizzabile in fase di registrazione). Real Name, invece, dovrebbe servire a sostituire, all'interno del portale, tutti i riferimenti all'utente con un field scelto dall'amministrazione (e quindi ad esempio un campo Nome_cognome al posto del prefisso dell'email).

Trackback nella mia sezione nel blog i-ware.

In una delle mie installazioni di drupal ho subito un attacco da parte di alcuni spammer.
Si sono iscritti circa 5000 utenti spam e ognuno di essi ha creato approssimativamente un contenuto.

Mi sono mosso per capire come cancellare nel modo più veloce utenti e contenuti in modo tale che nelle pagine admin/content/node e admin/user/user i risultati fossero maggiori, così da risparmiare tempo (di default sono 50).

Il risultato della ricerca per risolvere il problema è stato questo metodo:
Versione di drupal usata 6.16

Per cancellare 200 utenti per volta invece che 50 modificare il file modules/user/user.admin.inc andando alla funzione function user_admin_account() sostituire:
$result = pager_query($sql, 50, 0, $query_count, $filter['args']);
con:
$result = pager_query($sql, 200, 0, $query_count, $filter['args']);
e poi, qualche riga più avanti nello stesso file, sostituire:
$form['pager'] = array('#value' => theme('pager', NULL, 50, 0));
con:
$form['pager'] = array('#value' => theme('pager', NULL, 200, 0));
--------------------------------------------------------------

Per i contenuti modificare il file modules/node/node.admin.inc andando alla funzione function node_admin_nodes() sostituire:
$result = pager_query(db_rewrite_sql('SELECT n.*, u.name FROM {node} n '. $filter['join'] .' INNER JOIN {users} u ON n.uid = u.uid '. $filter['where'] .' ORDER BY n.changed DESC'), 50, 0, NULL, $filter['args']);
con:
$result = pager_query(db_rewrite_sql('SELECT n.*, u.name FROM {node} n '. $filter['join'] .' INNER JOIN {users} u ON n.uid = u.uid '. $filter['where'] .' ORDER BY n.changed DESC'), 200, 0, NULL, $filter['args']);
e poi, qualche riga più avanti nello stesso file, sostituire:
$form['pager'] = array('#value' => theme('pager', NULL, 50, 0));
con:
$form['pager'] = array('#value' => theme('pager', NULL, 200, 0));
--------------------------------------------------------
Quando si visterà la casella -seleziona tutti- il browser prenderà più tempo (diversi secondi) per completare l'operazione.
Ovviamente l'uso del DB si intensifica. Tenerne conto in caso si abbiano dei limiti imposti da proprio hosting.
Non superare il 200 item per non affaticare il sistema

Problema: gli articoli creati/modificati dagli utenti devono essere approvati da un editor prima di essere pubblicati.
Come spesso accade Drupal permette di ottenere lo stesso risultato seguendo approcci e soluzioni diverse; in questo caso integriamo il modulo workflow con il sistema di revisione dei contenuti e le azioni di Drupal.
Soluzione:
l'autore crea o modifica un contenuto; può salvarlo come bozza (impostandone lo stato = bozza), oppure inviarlo per revisione (stato = revisione). il contenuto non viene pubblicato.
Quando lo stato di un contenuto è impostato come revisione, l'editor viene avvertito con una email e allo stesso tempo l'autore non ha più il permesso di modificarne il contenuto.
L'editor rivede il contenuto e se lo reputa idoneo, lo pubblica (stato = approvato), altrimenti lo rimanda per revisione all'autore (stato = bozza) ed il ciclo ricomincia. In entrambi i casi l'autore può essere avvertito con una email.

Il flusso di lavoro si può schematizzare più o meno così:

Supponiamo che si voglia applicare questo workflow al tipo di contenuto story:

1. creare 2 ruoli: editor (permesso:administer nodes) e autore (permessi: crea story e modifica own story)
2. Contenuto->content types->story->edit (/admin/content/node-type/story): "workflow settings"->togliere la spunta a "pubblicato"; salvare
3. Attivare il modulo "trigger" (core - optional)
4. Configurazione del sito->Azioni (/admin/settings/actions)->"crea una nuova azione avanzata"->"invia una email"
   • Descrizione: "avverti editor" (avverte l'editor che è stato creato nuovo contenuto)
   • Destinatario: inserire indirizzo email dell'editor
   • Definire oggetto e corpo dell'email ricordando che è possibile usare i seguenti placeholders:
     • %username = nome utente dell'autore
     • %node_type = tipo di contenuto
     • %title = campo titolo del contenuto
     • %site_name = nome del sito
     • %node = full node e %teaser = teaser
5. ->"crea una nuova azione avanzata"->"invia una email"
   • Descrizione: "avverti autore" (avverte l'autore che il suo contenuto è in fase di moderazione)
   • Destinatario: inserire indirizzo email dell'autore utilizzando il placeholder %author*
   • Definire oggetto e corpo dell'email come già descritto
6. ->"crea una nuova azione avanzata"->"invia una email"
   • Descrizione: "richiedi revisione" (avverte l'autore che il suo contenuto deve essere rivisto)
   • Destinatario: inserire indirizzo email dell'autore utilizzando il placeholder %author*
   • Definire oggetto e corpo dell'email
7. volendo si può aggiungere un'ulteriore azione "conferma autore" per segnalare all'autore che il suo contenuto è stato pubblicato
8. Attivare il modulo workflow
9. Site building->workflow (/admin/build/workflow) -> Creare un nuovo workflow ed applicarlo al content type story
10. Creare gli stati BOZZA, REVISIONE, APPROVATO all'interno del nuovo workflow ed assegnare i permessi per i passaggi da uno stato all'altro secondo la tabella in alto
11. Site building->workflow->actions (/admin/build/workflow/actions); assegnare le azioni ai rispettivi triggers (vedi anche tabella):
    • da (creazione) a BOZZA-> nessuna azione
    • da (creazione) a REVISIONE-> "avverti editor" (e "avverti autore")
    • da BOZZA a REVISIONE-> "avverti editor" (e "avverti autore")
    • da REVISIONE a BOZZA-> "richiedi revisione"
    • da REVISIONE a APPROVATO-> "conferma autore", "pubblica contenuto" e "salva contenuto"

A questo punto, quando il ruolo "autore" crea una story dovrebbe poter impostare lo stato di BOZZA o REVISIONE, mentre il ruolo "editor" ha in aggiunta una opzione APPROVATO

*) NOTA: in alcuni casi il placeholder %author non funziona, probabilmente perchè il modulo trigger viene chiamato troppo presto. La soluzione (non sempre) può essere di aumentare il peso (weight) del modulo trigger (ad esempio da "0" a "2") nella tabella {system} del database.
Un'altra possibilità è usare l'azione avanzata "send a tokenized email" fornita dai moduli token e token_actions:
- abilitare i moduli token e token_ actions (incluso in token)
- andare su admin/settings/actions
- nel form "Rendi disponibile una nuova azione avanzata", scegliere "Send tokenized e-mail"
- nel campo "Destinatario" della nuova azione creata, scrivere il token [author-mail]
- configurare e sostituire due azioni di questo tipo a quelle impostate per "richiedi revisione" e "avverti autore"

NOTA: questo workflow ha un limite importante: una volta che un contenuto è stato pubblicato gli autori non possono più modificarlo (o possono modificarlo live in base ai permessi). i moduli revisioning+module_grants possono essere aggiunti a questo workflow permettendo la modifica "in revisione" dei contenuti, ovvero l'autore può modificare un contenuto pubblicato ma solo creando una nuova revisione che verrà pubblicata (e sostituirà la vecchia versione) solo dopo l'approvazione dell'editor. Questi moduli permettono anche configurazioni molto più complesse di questa.

Alcuni altri moduli per la moderazione dei contenuti:
http://drupal.org/project/content_moderation
http://drupal.org/project/revision_moderation
http://drupal.org/project/modr8
http://drupal.org/project/publishcontent
http://drupal.org/project/comment_moderation
Bonus: http://drupal.org/project/diff

CiviCRM-Drupal in realtà non è altro che un grande modulo, addirittura più pesante della cartella di installazione di Drupal 6 (infatti il peso dell'archivio è di circa 7,5mb - scompattato arriva a 37mb circa...).
Una volta scompattato, esplorando il contenuto possiamo notare che, al suo interno, c'è una cartella chiamata "drupal" che a sua volta contiene (oltre a diversi file...) la cartella "modules".
La prima cosa che verrebbe in mente (almeno a me...) è che il contenuto di questa cartella "modules", debba essere copiato nel solito percorso dei moduli > sites/all/modules, invece non è così.
La cartella "modules" contiene i moduli di CiviCRM-Drupal e va lasciata così (si, anche lasciando la cartella Joomla! con tutto il resto...).
Il modulo CiviCRM-Drupal, oltre che essere un modulo, per comprenderlo meglio, lo si potrebbe definire come una sorta di CMS dentro la sezione Moduli, infatti, richiede un'istallazione proprio come si fa con drupal 6 (ovviamente l'interfaccia dell'installer è completamente diversa...)

1. Creare un nuovo database per ospitare CiviCRM-Drupal
2. Scaricare CiviCRM-Drupal da qui > http://sourceforge.net/projects/civicrm/files/
3. Scompattare l'archivio e copiare la cartella "civicrm" (lasciando tutto il suo contenuto così com'è...) in http://www.miosito.com/sites/all/modules/
4. Procedere con l'installazione > http://www.miosito.com/sites/all/modules/civicrm/install/
5. Nella schermata che ci appare ci saranno dei "warning" in rosso - Per risolverli:
- Inserire i dati relativi ai 2 database (Drupal 6 e CiviCRM-Drupal)
- Settare i permessi della cartella "default" (http://www.miosito.com/sites/default) a 777
6. Lanciare l'installer (che si trova nell'interfaccia) et Voilà... CiviCRM è installato!
7. Rimettiamo a posto i permessi della cartella "default" a 644 (nel mio caso, su dreamhost.com, i permessi si sono settati in sola lettura a 555 automaticamente...).

Adesso, accedendo nel nostro Drupal 6 avremo nel menu admin una voce in più: CiviCRM

Se vogliamo poi localizzarlo in più lingue dobbiamo scaricare il file "civicrm-3.1.4-l10n.tar" (L10n) che si trova tra gli archivi da dove abbiamo prelevato CiviCRM > http://sourceforge.net/projects/civicrm/files/

IMPORTANTE! - Il modulo nella sezione moduli di drupal.org > http://drupal.org/project/civicrm NON VA NE CONSIDERATO NE SCARICATO - Tutto quello che serve è nel download > http://sourceforge.net/projects/civicrm/files/
Infatti, c'è anche scritto bello maiuscolo e in grassetto > http://drupal.org/project/civicrm appena sopra il link del download e, sinceramente non ho ancora capito a cosa serve tale link...

Un ringraziamento particolare a Francesco Moretto - http://www.civicrm.eu/ - per la sua gentile disponibilità, cortesia e collaborazione...

Ciao
Kipper

Oggetto:Realizzazione di una lista di checkbox all'interno di un form ordinate su più colonne.

DESCRIZIONE:
Premetto che non è farina del mio sacco, la trovai in giro qualche mese fa, e l'autore se vedrà questo articolo mi perdonerà se non metto il link al suo sito (nn mi ricordo nemmeno dove l'ho trovato).

Molte volte mi sono trovato a dover gestire un checkbox con molte scelte e ad avere quindi una lunga lista di campi uno di seguito all'altro ottenendo un form lungo un chilometro.
Questo piccolo HOWTO genera un nuovo type per i checkboxes da inserire all'interno del proprio modulo.

HOWTO
1) Nel proprio file .module inserire la seguente funzione:

<?php
/**
 * param array $element
 *   Elemento fapi da modificare.
 *
 * return array
 *   Elemento modificato.
 */
function _expand_checkbox_columns($element) {
  $value = is_array($element['#value']) ? $element['#value'] : array();
  $element['#type'] = 'checkboxes';
  $element['#tree'] = TRUE;
  if (count($element['#options']) > 0) {
    if (!isset($element['#default_value']) || $element['#default_value'] == 0) {
      $element['#default_value'] = array();
    }
    foreach ($element['#options'] as $key => $choice) {
      $class = $column && ($column % $element['#columns']) ? 'checkbox-columns' : 'checkbox-columns-clear';
      if (!isset($element[$key])) {
        $element[$key] = array(
          '#type' => 'checkbox',
          '#processed' => TRUE,
          '#title' => $choice,
          '#default_value' => in_array($key, $value),
          '#attributes' => $element['#attributes'],
          '#prefix' => '<div class="' . $class . '">',
          '#suffix' => '</div>',
        );
      }
      $column++;
    }
  }
  return $element;
}
/**
 * Implementation of hook_elements().
 */
function nomemodulo_elements() {
  $type['checkbox_columns'] = array(
    '#input' => TRUE,
    '#process' => array(
      '_expand_checkbox_columns' => array(),
    ),
    '#tree' => TRUE,
  );
  return $type;
}
?>

2) All'interno del form che si vuole generare potete utilizzare il type Checkbox_column come da esempio:

<?php
//....
  $numero_colonne = 3;
  $options = array(
    'en'=>t('English (US)'),
    'es'=>t('Español'),
    'fr'=>t('Français'),
    'it'=>t('Italiano'),
    'ar'=>t('Arabic'),
    'ur'=>t('Urdu'),
  );
  $results = db_query("SELECT lang FROM {newsletter_settings_lang};");
  $i = 0;
  $checked = array();
  while( $data = db_fetch_object($results)) {
    $checked[$i] = $data->lang;
    $i++;
  }
  $form['lingua'] = array(
    '#type' => 'checkbox_columns',
    '#title' => t('Seleziona le lingue abilitate per le newsletter'),
    '#columns' => $numero_colonne,
    '#options' => $options,
    '#suffix' => '<br style="clear:both;"/>',
    '#default_value' => $checked
  );
  // ....
?>

Infine bisogna inserire il seguente css all'interno dei propri stili (ad esempio in style.css del proprio tema)

Info generiche

• Drupal: 6.x, 5.x
• Licenza: Creative Commons By-Nc-Sa 2.5 - Italia
• Complessità: Principiante;

Ironicamente potrei definire questa classe di tutorial con il nome "Drupal Module-Less" perchè nella pratica di tutti i giorni tento sempre di realizzare qualcosa in Drupal senza necessariamente utilizare un apposito modulo, ma cerco di raggiungere lo stesso obiettivo che mi sono prefissato con i moduli che ho già a disposizione o meglio ancora utilizzando i moduli cosiddetti "essenzliali".
In questo tutorial realizzerò un sistema di licenziamento dei contenuti (nodi) di Drupal in perfetto stile Flickr utilizzando Content Type, Cck Node Reference, Cck Link e Path Auto. Penso siano moduli semplici e che nella maggior parte dei casi possono essere definiti moduli senza dei quali non si fa quasi nulla in Drupal.
1. Creare un Content Type “Licenza”
Per prima cosa bisogna creare un nuovo tipo di nodo andando in “Administration > Content Type > Add Content Type”, per esempio lo chiamiamo "Licenza", impostiamo poi i campi che ci vengono chiesti come meglio crediamo, per il momento non sono essenziali.

2. Path Auto dà un tocco di stile
Per facilitarne eventualmente la comprensione e la navigazione all'interno del nostro sito possiamo, tramite Path auto, assegnare una path visibilmente più piacevole ed accessibile, per esempio assegnando al nostro Content Type di tipo "Licenza" la path "licenza/[title-raw]", il che è induce che tutti i nodi di tipo "Licenza" saranno raggiungibili dalla path http://miodomino.it/license/Titolo-Del-Nodo e senza dubbio dà un tocco di serietà e allo stesso tempo le differenzia dai nodi veri e prori del sito.

Quindi andiamo “Administration > URL aliases > Automated alias settings”, scorrendo la pagina troveremo il blocco probabilmente collasato che riguarda i nodi dal nome “Node path settings”.

Decollassandolo troveremo la riga inerente al Content Type “Licenza” indicato probabolmente con “Pattern for all Licenza paths:”, ineriamo quindi nel campo sottostante “licenza/[title-raw]" ed attiviamo “Bulk generate aliases for nodes ...” ed infine applichiamo le modifiche.

3. Aggiungiamo qualche Field utile
3.1 Content Type: Licenza
Nel nostro caso utilizzeremo il campo "Titolo" e "Body" che Drupal ci offre in modalità di default, inserendo nel "titolo" ad esempio il nome completo della licenza e nel "body" un riassunto esplicativo della licenza, non mi sembra il caso di inserire il testo completo o il legal code qui dentro.
Infatti quest'ultimi campi gli inseriremo con degli utili link a fondo del nodo tramite l'aggiunta di alcuni "Field" utili, per fare questo spostiamoci in “Home > Administer > Content management” e clicchiamo sulla voce “Manage Fields” in corripondenza del Content Type “Licenza”.

Aggiungiamo un “Field” di tipo “cck Link” e gli assegnamo il nome che preferiamo, ad ogno modo teniamo bene a mente che in questo campo saranno inseriti una serie di “link utili” a rendere comprensibile e valida giuridicamente il riassunto che abbiamo inserito nel campo “Body”.

Personalmente ho limitato il numero di “Fields” aggiuntivi ad uno solo, ma per esigenze stilistiche o di usabilità potreste adattare questa parte come meglio credete, per esempio si potrebbe suddividere il tutto inserendo compi come dal nome “Legal Code”, “Traduzione”, “Logo” ecc.

3.2 Gli altri Content Type
A questo punto non ci tocca che aggiungere la possiblità di “collegare” le licenze ai nodi che preferiamo, spostiamoci su “Home > Administer > Content management” e clicchiamo sulla voce “Manage Fields” in corrispondenza del nodo a cui siamo interessati applicare la possibilità di licenziarlo con questo sistma fatto in casa.

Ad esempio clicchiamo su “Manage Fields” in corrispondenza del “Page”, scorrendo anche qui la pagina aggiungiamo un “field” a cui applichiamo il nome “Licenza” e selezioniamo adesso il field “Node Reference”. A questo punto ci verrà chiesto quale dei nodi dovremo poter collegare, ovviamente selzioniamo il Content Type “Licenza” che abbiamo appena creato.

Anche qui possiamo un po' gestirci le altre impostazioni come meglio crediamo, personalmente ho messo come valore di default “None” cioè nessun nodo selezionato, mentre potrebbe essere utile selezionare una Licenza particolare come valore di default. A voi la scelta.

4. Conclusioni
Spero di essere stato chiaro e soprattutto utile, non è certo una guida che ci cambia la vita, ma probabilmente dimostra come con un po' di tempo a disposizione e un po' di logica possiamo creare funzionalità molto interessanti senza l'uso di alcun modulo aggiuntivo.
Vi elenco di seguito alcuni link del mio personale risultato di questa modalità di Licenziamento dei contenuti in perfetto stile Flickr.

Link dell'articolo in PDF

Esempio
http://www.pillsofbits.com/guida/5-moduli-essenziali-un-progetto-basato-...
http://www.pillsofbits.com/licenza/attribuzione-non-commerciale-condivid...
http://www.pillsofbits.com/licenza/

L'esempio crea un sotto tema da Garland, ma è sufficientemente generico per qualsiasi tema (spero).

1. Decidere il nome.
Un nome a singola parola va bene, seguendo le regole per i nomi delle variabili di PHP. Ho scelto drupalitalia.

2. Creare il percorso per il tema.
Puoi metterlo in sites/all/themes o sites/default/themes. Ho scelto sites/all/themes/drupalitalia. Controlla che i permessi siano identici rispetto a quelli di themes/garland. Per riuscire ad editare i file potrebbe essere necessario cambiare il gruppo, e mettere i permessi a 775.

3. Preparare il tema.
Bisogna creare solo pochi file per il tema. Il primo, e più importante, è drupalitalia.info. Il file deve usare il nome del tema - drupalitalia, e l'estensione .info. Qui dobbiamo specificare una serie di parametri del tema (vedi http://drupal.org/node/171205).

Tutto copiato dal tema originale, con qualche eccezione:

• base theme bisogna pur dire da quale tema vogliamo ereditare la funzionalità - devi usare la nome 'macchina' cioè il nome usato per il file .info
• stylesheets[all][] oltre ai file CSS dell'originale specifichiamo anche uno nostro.
• scripts[] oltre ai file JavaScript dell'originale (se ci sono) specifichiamo anche uno nostro.
• regions[drupalitalia] oltre ai famosi cinque aggiungiamo anche una regione nostra (perche no?)

Il secondo file sarà proprio il file CSS che abbiamo appena definito, drupalitalia.css - ovviamente possiamo darlo un nome qualsiasi, basta che corresponda con quello definito nel file .info:


/* CSS per il nostro tema */
body {
  font-family: monospace;
}

Cambiamo il font per dare un feedback visivo e per controllare che tutto funziona - poi lo elimineremo.

Il terzo file sarà proprio il file JavaScript che abbiamo definito, drupalitalia.js - di nuovo possiamo dare un nome qualsiasi, basta che corresponda con quello definito nel file .info:


/* JavaScript per la nostra tema */

E' vuoto per il momento, magari più avanti avremo bisogno di mettere codice qui.

Il prossimo file è template.php, che finirà per contenere codice di temizzazione, se necessario:


<?php
// Codice di temizzazione specifico per la tema
/**
* Override o inserire variabili per page.tpl.php.
* Vedi http://api.drupal.org/api/function/template_preprocess_page/6
*/
function drupalitalia_preprocess_page(&$vars) {
  // vuota per ora...
}
/**
* Override o inserire variabili per node.tpl.php.
* Vedi http://api.drupal.org/api/function/template_preprocess_node/6
*/
function drupalitalia_preprocess_node(&$vars) {
  // vuota per ora...
}

Altro file 'vuoto' per il momento. Ho semplicemente aggiunto due funzioni di cui quasi sicuramente avremo bisogno in futuro.
Si, manca un ?> finale - non è un errore, fidati.

In fine dovremo modificare page.tpl.php aggiungendo la regione che abbiamo creato. Per fare questo, basta copiare page.tpl.php da themes/garland in sites/all/themes/drupalitalia. E' un file grosso, quindi non metto tutto il contenuto qui, solo le ultime righe dove aggiungiamo nostra regione:


    ...
    </div> <!-- /container -->
  </div>
  <!-- nostra regione aggiunto -->
  <div id="special-region" class="clear-block"><?php print $drupalitalia; ?></div>
<!-- /layout -->
  <?php print $closure ?>
  </body>
</html>

4. Testare la tema.
Fatto. Adesso andiamo in admin/build/themes, dove troviamo un nuovo tema (oooh) chiamato "Drupalitalia - modificato Garland". Clicca su attiva e predefinito, poi 'Salva configurazione' (incrociando le dita). Se tutto va bene, la maggior parte del testo sarà monospace come questo - il nostro controllo visivo che tutto va bene.

Poi controlliamo la nostra nuova regione. Andiamo in admin/build/block/list/drupalitalia dove, nella lista di regioni, prima di 'Disattivato' troviamo 'Speciale per questo tema' mettiamo dentro 'Realizzato con Drupal (module: system)' poi 'Salva blocchi' et voilà mes amis! La goccia è in fondo alla pagina.

Ma c'è un piccolo problema - abbiamo perso il logo nel header. Basta copiare logo.png da themes/garland in sites/all/themes/drupalitalia.

Per i pigri tutti i file sono in allegato. Formatto zip per gli appasionati di Windows.

I file *.tpl.php

Il concetto di tema

Il file *.info

Il file template.php

Il funzionamento di phptemplate

Integrazione con color e advanced theme

Stato documento: Alfa

Spesso la sequenza di temizzazione (rendering) della pagina in Drupal crea confusione. Dopo qualche ore tentando di seguire il codice, ho deciso di tagliare corto, ed installare un pò di codice per creare un X-Ray del processo. Questo dà un pò più informazione di quello disponibile usando Devel e Theme Developer.

Il codice della macchina a raggi X
Ho aggiunto qualche riga di codice in includes/theme.inc, e giusto che puoi sperimentare per conto proprio, ti spiego le modifiche. Bisogna 'catturare' informazione durante le chiamate a theme() ed a template_preprocess()
Iniziamo subito, alla riga 577, inserisci:

<?php
 function theme() {
  $args = func_get_args();
  $hook = array_shift($args);
?>

<?php
global $drupal_calls;
if (!isset($drupal_calls)) { $drupal_calls = array(); }
$drupal_calls[] = "theme(start): ". $hook ."\n";
?>

<?php
  static $hooks = NULL;
?>

<?php
  // Add final markup to the full page.
  if ($hook == 'page' || $hook == 'book_export_html') {
    $output = drupal_final_markup($output);
  }
?>

Poi viene temizzato il nodo vero e proprio, caricando il nodo completo tramite template_preprocess_node() (nota che theme() viene chiamato ricursivamente):

In fine, viene temizzato la pagina, chiamando template_preprocess_page():