Planet Drupal Italia
VIews styler
Precedentemente avevo scritto una patch per views che pemetteva di andare ad indicare delle classi specifiche alle singole righe delle views. Considerato che modificare il codice di un modulo lo considero una delle cose più pericolose nonché sbagliate, e in considerazione del fatto dell'enorme modularità raggiunta da Drupal 7 con le funzioni di autoloading, ho deciso di separare la patch creando un modulo apposito. Attualmente questo modulo si trova in una sandbox, vediamo come ottenerlo e come usarlo (e perché!).
L'installazioneViews 3 e Grid system (patch)
Ultimamente, lavorando con Omega in diversi siti, mi è capitato di dover fare un pò di "magie" per riuscire ad ottenere il risultato desiderato. Il problema principale che ho riscontrato è che le views permettono di aggiungere classi ai singoli field, al wrapper della vista stessa, o una classe uguale per tutti le righe, ma non permette di inserire classi personalizzate per ogni riga. Questo, nelal versione per Drupal 6 e views 2, era risolvibile ricorrendo a Semantic Views, ma per Views 3 non abbiamo ancora uno strumento che ci permette di fare quanto richiesto. Per risolvere questo problema ho scritto una piccola patch (attenzione, non mi assumo responsabilità in merito :) ) che permette di definire per ogni singola riga, o per righe particolari (prima/ultima, pari/dispari) delle classi specifiche. Vediamo come applicare questa patch e come funziona.
Omega 3, aggiungiamo le nostre griglie
Chi avesse iniziato ad utilizzare Drupal 7 si sarà senz'altro d'accordo che stanno nascendo dei temi di partenza molto sofisticati da cui partire per la realizzazione di temi, in particolare sta emergendo sempre più Omega 3.
Questi temi, però possono avere necessità di essere estesi per aggiungere nuove funzonalità, in particolare potremmo avere necessità di usare una griglia differente da quelle che queesto tema di partenza ci mette a disposizione; vediamo quindi come aggiungere una griglia customizzata nel nostro sottotema di Omega 3.
Le sessioni secondo Drupal
Drupal per tenere traccia delle sessioni degl utenti salva le informazioni relative ai navigatori all'interno del suo database, infatti tutti dati relativi alle sessioni vengono salvate in una tabella chimata 'session'.
Il sistema reagisce all'ingesso di un visitatore sul sito creando una nuova riga nella tabella session. La riga creata inizialmente viene generata per l'utente anonimo (UID = 0) nel momento che l'utente effettua un login la riga verrà contrassegnata con l'UID dell'utente.
Ogni navigatore che accede al nostro sito Drupal lascia quindi una traccia all'interno della nostra tabella 'session' e pertanto periodicamente il sistema deve provvedere a pulire la tabella dei dati non piu necessari altrimenti la tabella crescerebbe all'infinito con le naturali conseguenze che questo comporta.
Per default all'interno del nostro setting.php del nostro sito Drupal troviamo:
La riga sopra configura il "Garbage Collector" (lo spazzino) di PHP a pulire le sessioni piu vecchie di 23 giorni. La pulizia viene fatta direttamente dal GC che dovrebbe essere attivo ma spesso alcune distribuzioni (es Debian, Ubuntu) o alcuni hoster (Unbit) configurano il GC come spento e pertanto il povero spazzino non è autorizzato a svuotare la tabella session e questa continua a riempirsi crescendo di fatto all'infinito.
Le righe qui sotto se aggiunte al setting.php servono ad attivare il GC nel caso la nostra istanza di PHP abbia la sfortuna di avere il GC spento.
ini_set('session.gc_divisor', 100); // Il divisore della probabilità
L'attivazione del Garbage Collector di PHP come in altri linguaggi non è deterministica ed infatti le direttive sopra configurano la probabilità che il GC si attivi e faccia pulizia. Nello specifico i due parametri sopra impostano l'attivazione del GC con una probabilità di 1/100 all'attivazione di una nuova sessione.
Questa soluzione di default in Drupal si basa direttamente su primitive PHP ma se per motivi vari non possiamo utilizzarla( o non ci è concessa) ci sono svariate maniere per tenere sotto controllo la dimensione della taballa session.
Alternativa 1Una prima soluzione semplice al problema è installare il modulo session_expire
Alternativa 2Una seconda soluzione è lasciar fare al db la pulizia!!
CREATE EVENT event_db1_session_clean
ON SCHEDULE EVERY 1 DAY
DO
DELETE FROM db1.sessions WHERE timestamp < UNIX_TIMESTAMP( ADDDATE( NOW( ) , INTERVAL -10 DAY ) )
Il pezzo di SQL (per MySql) di sopra crea un evento(è l'equivalente del cron di linux) che quando sarà ora eseguirà la query di pulizia della tabella, con questa soluzione la tabella tutti i giorni verrà pulita direttamente dal motore di MySql.
Alternativa 3Una terza soluzione è uno script di 5 righe nel cron
Quando l'alternativa diventa miglioriaCome abbiamo visto sopra ci sono svariati modi di tenere sotto controllo la tabella session ma nel caso di un sito molto trafficato la soluzione di default potrebbe non essere "geniale" perchè la pulizia avviene svariate volte al giorno in momenti non predicibili stressando ulteriormente il server web del sito. Le soluzioni alternative essendo predicibili (soprattutto la 2 e la 3) possono in alcuni casi essere considerate soluzioni migliori al problema di "maintenance" della tabella session.
Tags Drupal Drupal 6Le sessioni secondo Drupal
Drupal per tenere traccia delle sessioni degl utenti salva le informazioni relative ai navigatori all'interno del suo database, infatti tutti dati relativi alle sessioni vengono salvate in una tabella chimata 'session'.
Il sistema reagisce all'ingesso di un visitatore sul sito creando una nuova riga nella tabella session. La riga creata inizialmente viene generata per l'utente anonimo (UID = 0) nel momento che l'utente effettua un login la riga verrà contrassegnata con l'UID dell'utente.
Ogni navigatore che accede al nostro sito Drupal lascia quindi una traccia all'interno della nostra tabella 'session' e pertanto periodicamente il sistema deve provvedere a pulire la tabella dei dati non piu necessari altrimenti la tabella crescerebbe all'infinito con le naturali conseguenze che questo comporta.
Per default all'interno del nostro setting.php del nostro sito Drupal troviamo:
La riga sopra configura il "Garbage Collector" (lo spazzino) di PHP a pulire le sessioni piu vecchie di 23 giorni. La pulizia viene fatta direttamente dal GC che dovrebbe essere attivo ma spesso alcune distribuzioni (es Debian, Ubuntu) o alcuni hoster (Unbit) configurano il GC come spento e pertanto il povero spazzino non è autorizzato a svuotare la tabella session e questa continua a riempirsi crescendo di fatto all'infinito.
Le righe qui sotto se aggiunte al setting.php servono ad attivare il GC nel caso la nostra istanza di PHP abbia la sfortuna di avere il GC spento.
L'attivazione del Garbage Collector di PHP come in altri linguaggi non è deterministica ed infatti le direttive sopra configurano la probabilità che il GC si attivi e faccia pulizia. Nello specifico i due parametri sopra impostano l'attivazione del GC con una probabilità di 1/100 all'attivazione di una nuova sessione.
Questa soluzione di default in Drupal si basa direttamente su primitive PHP ma se per motivi vari non possiamo utilizzarla( o non ci è concessa) ci sono svariate maniere per tenere sotto controllo la dimensione della taballa session.
Alternativa 1Una prima soluzione semplice al problema è installare il modulo session_expire
Alternativa 2Una seconda soluzione è lasciar fare al db la pulizia!!
CREATE EVENT event_db1_session_clean
ON SCHEDULE EVERY 1 DAY
DO
DELETE FROM db1.sessions WHERE timestamp
Il pezzo di SQL (per MySql) di sopra crea un evento(è l'equivalente del cron di linux) che quando sarà ora eseguirà la query di pulizia della tabella, con questa soluzione la tabella tutti i giorni verrà pulita direttamente dal motore di MySql.
Alternativa 3Una terza soluzione è uno script di 5 righe nel cron
Quando l'alternativa diventa miglioriaCome abbiamo visto sopra ci sono svariati modi di tenere sotto controllo la tabella session ma nel caso di un sito molto trafficato la soluzione di default potrebbe non essere "geniale" perchè la pulizia avviene svariate volte al giorno in momenti non predicibili stressando ulteriormente il server web del sito. Le soluzioni alternative essendo predicibili (soprattutto la 2 e la 3) possono in alcuni casi essere considerate soluzioni migliori al problema di "maintenance" della tabella session.
Tags Drupal Drupal 6Le sessioni secondo Drupal
Drupal per tenere traccia delle sessioni degl utenti salva le informazioni relative ai navigatori all'interno del suo database, infatti tutti dati relativi alle sessioni vengono salvate in una tabella chimata 'session'.
Il sistema reagisce all'ingesso di un visitatore sul sito creando una nuova riga nella tabella session. La riga creata inizialmente viene generata per l'utente anonimo (UID = 0) nel momento che l'utente effettua un login la riga verrà contrassegnata con l'UID dell'utente.
Ogni navigatore che accede al nostro sito Drupal lascia quindi una traccia all'interno della nostra tabella 'session' e pertanto periodicamente il sistema deve provvedere a pulire la tabella dei dati non piu necessari altrimenti la tabella crescerebbe all'infinito con le naturali conseguenze che questo comporta.
Per default all'interno del nostro setting.php del nostro sito Drupal troviamo:
- ini_set('session.cookie_lifetime', 2000000); // Circa 23 Giorni
La riga sopra configura il "Garbage Collector" (lo spazzino) di PHP a pulire le sessioni piu vecchie di 23 giorni. La pulizia viene fatta direttamente dal GC che dovrebbe essere attivo ma spesso alcune distribuzioni (es Debian, Ubuntu) o alcuni hoster (Unbit) configurano il GC come spento e pertanto il povero spazzino non è autorizzato a svuotare la tabella session e questa continua a riempirsi crescendo di fatto all'infinito.
Le righe qui sotto se aggiunte al setting.php servono ad attivare il GC nel caso la nostra istanza di PHP abbia la sfortuna di avere il GC spento.
- ini_set('session.gc_probability', 1); // Probabilta che il GC parta
- ini_set('session.gc_divisor', 100); // Il divisore della probabilità
L'attivazione del Garbage Collector di PHP come in altri linguaggi non è deterministica ed infatti le direttive sopra configurano la probabilità che il GC si attivi e faccia pulizia. Nello specifico i due parametri sopra impostano l'attivazione del GC con una probabilità di 1/100 all'attivazione di una nuova sessione.
Questa soluzione di default in Drupal si basa direttamente su primitive PHP ma se per motivi vari non possiamo utilizzarla( o non ci è concessa) ci sono svariate maniere per tenere sotto controllo la dimensione della taballa session.
Alternativa 1Una prima soluzione semplice al problema è installare il modulo session_expire
Alternativa 2Una seconda soluzione è lasciar fare al db la pulizia!!
- CREATE EVENT event_db1_session_clean
- ON SCHEDULE EVERY 1 DAY
- DO
- DELETE FROM db1.sessions WHERE timestamp < UNIX_TIMESTAMP( ADDDATE( NOW( ) , INTERVAL -10 DAY ) )
Il pezzo di SQL (per MySql) di sopra crea un evento(è l'equivalente del cron di linux) che quando sarà ora eseguirà la query di pulizia della tabella, con questa soluzione la tabella tutti i giorni verrà pulita direttamente dal motore di MySql.
Alternativa 3Una terza soluzione è uno script di 5 righe nel cron
Quando l'alternativa diventa miglioriaCome abbiamo visto sopra ci sono svariati modi di tenere sotto controllo la tabella session ma nel caso di un sito molto trafficato la soluzione di default potrebbe non essere "geniale" perchè la pulizia avviene svariate volte al giorno in momenti non predicibili stressando ulteriormente il server web del sito. Le soluzioni alternative essendo predicibili (soprattutto la 2 e la 3) possono in alcuni casi essere considerate soluzioni migliori al problema di "maintenance" della tabella session.
Tags: Drupal, Drupal 6Le sessioni secondo Drupal
Drupal per tenere traccia delle sessioni degl utenti salva le informazioni relative ai navigatori all'interno del suo database, infatti tutti dati relativi alle sessioni vengono salvate in una tabella chimata 'session'.
Il sistema reagisce all'ingesso di un visitatore sul sito creando una nuova riga nella tabella session. La riga creata inizialmente viene generata per l'utente anonimo (UID = 0) nel momento che l'utente effettua un login la riga verrà contrassegnata con l'UID dell'utente.
Migrare dati a Drupal
Nella realizzazione di portali o nella fase di migrazione da una piattaforma ad un altra spesso di riscontra la necessità di effettuare l'inserimento / trasferimento di dati. Fino a che le informazioni sono limitate è conveniente effettuare ua migrazione manuale, permettendo di trasferire le inforazioni in maniera pulita ed eventualmente procedendo ad effettuare tutte le modfiche di markup e struttura necessarie; ma cosa succede se le quantità di informazioni da trasferire sono in numero tale da non consentirci di procedere in maniera manuale?
Analizzeremo ora alcuni tool e tecniche che possono essere utilizzati per migrare grandi quantitativi di dati da una piattaforma X a Drupal, vedendo successivamente come estendere queste funzionalità per poter effettuare operazioni personalizzate sulla propria base dati.
Drupal e image optimizer
Se vi capita di utilizzare YSlow o PageSpeed per analizzare le performance del vostro front end, può capitare di vedere una voce che vi indica che le vostre immagini non sono ottimizzate. Cosa vuol dire, ma sopratutto, come possiamo ottimizzarle per ottenere dei risultati migliori? Questo è quello di cui parleremo ora, in particolare vedremo come integrare queste ottimizzazioni in Drupal.
DrupalCamp 2010
Il 2 ottobre 2010, per secondo anno consecutivo, si svolgerà l'evento italiano su Drupal aperto a tutti coloro che vogliono conoscere meglio il magico mondo della "goccia".
L'evento è completamente gratuito e si svolgerà presso i locali della cascina roccafranca di Torino.
Quest'evento è il primo organizzato ufficilmente dall' associazione drupal italia nata con il preciso intento di aiutare la diffusione di drupal sul territorio italiano.
Tags Drupal Drupal Comunity DrupalCampDrupalCamp 2010
Il 2 ottobre 2010, per secondo anno consecutivo, si svolgerà l'evento italiano su Drupal aperto a tutti coloro che vogliono conoscere meglio il magico mondo della "goccia".
L'evento è completamente gratuito e si svolgerà presso i locali della cascina roccafranca di Torino.
Quest'evento è il primo organizzato ufficilmente dall' associazione drupal italia nata con il preciso intento di aiutare la diffusione di drupal sul territorio italiano.
Tags Drupal Drupal Comunity DrupalCampDrupalCamp 2010
Il 2 ottobre 2010, per secondo anno consecutivo, si svolgerà l'evento italiano su Drupal aperto a tutti coloro che vogliono conoscere meglio il magico mondo della "goccia".
L'evento è completamente gratuito e si svolgerà presso i locali della cascina roccafranca di Torino.
Quest'evento è il primo organizzato ufficilmente dall' associazione drupal italia nata con il preciso intento di aiutare la diffusione di drupal sul territorio italiano.
Tags: Drupal, Drupal Comunity, DrupalCampDrupalCamp 2010
Il 2 ottobre 2010, per secondo anno consecutivo, si svolgerà l'evento italiano su Drupal aperto a tutti coloro che vogliono conoscere meglio il magico mondo della "goccia".
L'evento è completamente gratuito e si svolgerà presso i locali della cascina roccafranca di Torino.
Quest'evento è il primo organizzato ufficilmente dall' associazione drupal italia nata con il preciso intento di aiutare la diffusione di drupal sul territorio italiano.
In partenza per la drupalCON
Che dire,
sono in partenza per l'attesissima Drupalcon di Copenhagen, è la prima volta che partecipo ad un evento "maggiore" di drupal e sono contento di partire.
Per chi è gia la ... STO ARRIVANDO!
Tags Drupal Drupal Comunity DrupalconIn partenza per la drupalCON
Che dire,
sono in partenza per l'attesissima Drupalcon di Copenhagen, è la prima volta che partecipo ad un evento "maggiore" di drupal e sono contento di partire.
Per chi è gia la ... STO ARRIVANDO!
Tags Drupal Drupal Comunity DrupalconIn partenza per la drupalCON
Che dire,
sono in partenza per l'attesissima Drupalcon di Copenhagen, è la prima volta che partecipo ad un evento "maggiore" di drupal e sono contento di partire.
Per chi è gia la ... STO ARRIVANDO!
Tags: Drupal, Drupal Comunity, DrupalconIn partenza per la drupalCON
Che dire,
sono in partenza per l'attesissima Drupalcon di Copenhagen, è la prima volta che partecipo ad un evento "maggiore" di drupal e sono contento di partire.
Per chi è gia la ... STO ARRIVANDO!
Chiamate cookieless in Drupal
Come visto negli articoli precedenti riguardanti le chiamate cookieless e le ottimizzazioni del front end di Drupal ci sono diversi modi per migliorare il modo in cui è possibile effettuare l'ottimizzazione del frontend. Ora vedremo come integrare alcune delle cose viste nei due articoli precedenti e come migliorare ulteriormente le performance con Drupal.
Per aggiungere il tuo Feed XML riguardante Drupal, compila il form Planet.
Pagine
