Le applicazioni web possono essere visualizzate su dispositivi con caratteristiche hardware molto differenti tra di loro.
La dimensione dello schermo del dispositivo è la caratteristica tecnica principale che segna la linea di confine tra il vedere l’applicazione web nel suo aspetto originale e l’utilizzare una visualizzazione mobile per mostrare il contenuto.
La versione mobile di un sito può essere di due tipi: una applicazione o un tema grafico tagliato a misura dei dispositivi mobili.
L’applicazione deve essere scritta per il specifico dispositivo per la quale viene pensata. A tale scopo sono disponibili diversi framework che traducono l’applicazione in linguaggio macchina del dispositivo.
Il principale vantaggio dell’applicazione è che utilizza caratteristiche e funzioni del sistema operativo montato sul dispositivo, potendo disporre anche delle feature che il sistema mette a disposizione (per esempio sviluppando una applicazione per iphone si può sfruttare il fatto che il telefonino lo si può scuotere – funzione shake – e progettare l’applicazione in modo che risponda in un determinato modo se lo shake è usato; altro esempio per dispositivi apple l’utilizzo di più dita per navigare e il poter tracciare diverse gestures nell’utilizzo dell’applicazione)
Nel caso di utilizzo di una applicazione in pratica non viene usato un browser e un linguaggio di programmazione web per consultarlo. Il database viene utilizzato solo come deposito di contenuti richiamati dalla app stessa nel suo linguaggio.
Lo svantaggio dell’utilizzo dell’applicazione è che va scritta una app per ogni gruppo di dispositivi esistenti (app per blackberry, app per android, app per prodotti apple).
Alternativa alla applicazione è la costruzione di un tema grafico fruibile via browser web installato su dispositivi mobili.
NB che con tema grafico non si intendo solo l’utilizzo di un foglio di stile differente, ma il caricamento di un vero e proprio template nel quale gli oggetti sono disposti diversamente, dove possono essere aggiunti elementi e rimossi altri non necessari nella navigazione su dispositivi con risoluzione limitata.
L’informazione che viene utilizzata per discriminare l’utilizzo o meno di un template per mobile è lo User-Agent.
Lo User-Agent è una informazione appartenente al client che identifica browser, versione del browser, sistema operativo e lingua
L’applicazione web si prende carico del compito di controllare lo User-Agent che sta visitando il sito, decidere se si tratta di un dispositivo per il quale è necessario il tema mobile.
Dove risiede però il criterio o i criteri tramite i quali si decide cosa fare?
Non esiste un criterio matematico, ma il criterio comunemente utilizzato è una lista testuale da consultare che elenca gli user-agent dei dispositivi mobili.
La lista può essere locale (ossia sul server che ospita l’applicazione) o remota (quindi la consultazione di un file o di un database remoto con la lista)
In pratica, se lo user agent è tra quelli presenti nella lista viene caricato il template mobile.
Utilizzo in Drupal:
Esistono 4 moduli per effettuare questo redirect in Drupal:
- WURFL
- Browscap
- Mobile Tools
Il funzionamento di questi 4 moduli non prevede il caricamento diretto del template mobile proseguendo la navigazione nella stessa URL quanto piuttosto in redirect verso – in genere – un dominio di terzo livello.
Questo viene fatto perché così l’informazione riguardante il metodo di navigazione dell’utente non deve essere memorizzata (localmente tramite cookie o dal server tramite sessione) e ricontrollata ad ogni richiesta.
Effettuato il redirect verso il dominio di terzo livello la navigazione prosegue senza ulteriori controlli
Descrizione dei moduli:
WURFL
E’ un modulo semplice e minimale.
Effettua il controllo sul dispositivo che visita il sito basandosi sulla libreria WURFL PHP library la quale consulta un file xml locale e ritorna il tipo di dispositivo.
Il file xml è da aggiornare manualmente.
Il criterio con cui fa la distinzione si basa sul tipo di dispositivo (non sul browser) usato.
http://drupal.org/project/wurfl
Browscap
Funziona allo stesso modo di WURFL con la differenza che consulta in un primo momento un file remoto (browscap.ini) messo a disposizione dallo sviluppatore della libreria.
Dopo la consultazione del file viene aggiornata una tabella del database (sempre locale) che evita mal configurazioni nel file in caso di interventi manuali.
Il criterio di classificazione degli user-agent è la consultazione del browser.
http://drupal.org/project/browscap
Mobile Tools
Modulo più completo.
Si integra sia con WURFL che con Browscap dei quali sfrutta la classificazione del dispositivo per migliorare il detect.
Fornisce una interfaccia di amministrazione tramite la quale è possibile creare condizioni di redirect.
Si integra con molti altri moduli aggiuntivi di Drupal.
http://drupal.org/project/mobile_tools
Problemi conosciuti
I motivi che causano il malfunzionamento di questi moduli sono motivi esclusivamente riconducibili alla cache del sito nella navigazione per utenti anonimi. Più precisamente a moduli che estendono la cache nativa di Drupal, come ad esempio Boost.
Boost è un modulo che staticizza le pagine periodicamente (con tempi a scelta dell’utente) le comprime e le dà in pasto al browser nel momento in cui vengono richieste. Questo inibisce l’opportunità di effettuare richieste lato server (quindi di controllare il dispositivo utilizzato), e di utilizzare sempre la pagina cachizzata.
Per risolvere questo problema di può procedere in tre direzioni: modificare il modulo boost in modo da non fargli memorizzare in cache la Home Page, abbassare il controllo a lato client o alzarlo ad un livello più alto del server rispetto al linguaggio di programmazione.
Modificare il modulo boost
Permetterebbe l’esecuzione del codice php della pagina e conseguentemente il suo controllo sul browser.
Non funziona per i link diretti alle pagine (ad esempio i link che arrivano dai risultati dei motori di ricerca) o i link diretti interni del sito.
Abbassare il livello nel client
E’ la soluzione intuitivamente più veloce, permette di intercettare in fretta alcuni dispositivi. Ha delle controindicazioni:
- L’utente (o chi per lui – un modulo aggiuntivo) può disabilitare javascript facendo saltare il controllo.
- Non tutti i browser per dispositivi mobili supportano javascript, e il controllo salta.
- Il controllo lato client è a carico della macchina dell’utente.
Alzare il controllo nel livello server
E’ la soluzione più sicura ma anche la più complicata da attuare.
Si può procedere in due modi:
Scrittura di regole nel file .htaccess
Le regole devono essere scritte nel modo più preciso possibile, non è possibile consultare una lista esterna e dinamica rispetto al file quindi va tutto scritto all’interno
Il vantaggio è quello di poter innalzare il livello della distinzione pur mantenendo separata la gestione dominio per dominio.
Filtro installato sul server
E’ possibile rendere disponibile il filtro WURFL non solo ai linguaggi di programmazione dinamica come php, o javascript, ma a tutti i linguaggi.
Conseguentemente è stato scritto un modulo aggiuntivo di apache che sfrutta il filtro WURFL
http://www.idelfuschini.it/apache-mobile-filter-v2x.html
Lo svantaggio è che essendo un filtro a livello di apache è ancora a livello più alto dell’htaccess e ingloba dentro di se tutti i domini creati sul server.
Inoltre essendo una modifica su apache ci vuole la conoscenza tecnica per effettuare l’installazione e la configurazione in maniera corretta senza minarne in funzionamento.
Conclusioni
La via migliore per siti fatti in drupal è quella di installare il modulo mobile tools per avere una buona gestione dei redirect e delle condizioni di reindirizzamento tramite il pannello di controllo e di accoppiarlo con uno dei due metodi di detect, wurfl o browscap.
Inoltre, nel caso fosse installato il modulo integrativo della cache boost aggiungere al file .htaccess nella root del dominio regole che effettuino il controllo e il redirect prima di processare il file php preservando così la cache statica creata dal modulo.
Risorse:
http://wurfl.sourceforge.net http://drupal.org/node/681396 http://www.projectronin.com/blog/?p=10 http://sourceforge.net/projects/mobilefilter/ http://ohryan.ca/blog/tag/mobile-browser/ http://drupal.org/node/1214890 http://cruncht.com/417/mobile-drupal-groundwork/ http://www.mediacurrent.com/blog/going-mobile-drupal http://drupal.org/project/mobile_tools http://drupal.org/project/browscap http://drupal.org/project/wurfl
La situazione cui ci troviamo di fronte è quella di avere una installazione di Drupal funzionante, e di aggiungere una cartella “stats” dentro cui carichiamo i file *.pl per leggere le statistiche awstats del sito.
Supponiamo inoltre di voler proteggere la directory con password per renderla accessibile solo al cliente. La protezione con password è da effettuarsi tramite il cpanel.
Le imposstazioni di prtezione della cartella però vanno in conflitto con le direttive scritte dentro il file .htaccess di drupal; per rendere funzionante il meccanismo è necessario effettuare qualche modifica:
- Creare un file 401.html e caricarlo sia nella root che nella cartella da proteggere
- Aggiungere una direttiva al file .htaccess della root del sito
- Aggiungere due direttive al file .htaccess che risiede dentro la cartella protetta
Creare file 401.html
Creare un file di testo, nominarlo 401.html e al suo interno incollare il seguente codice
|
1 2 3 4 5 6 |
<html> <head><title>401 Password Needed</title></head> <body><h1>401 Password Needed</h1> <p>You don't have permission to access this folder.</p> </body> </html> |
Caricare il file nella root dell’installazione di Drupal, e dentro la cartella protetta da password
Direttiva dentro l’htaccess nella root dell’installazione
Aprire il file .htaccess che risiede nella root dell’installazione di drupal, in cima, sotto al codice
|
1 |
ErrorDocument 404 /index.php |
aggiungere
|
1 |
ErrorDocument 401 /401.html |
e salvare.
Direttive dentro al file .htaccess che risiede dentro la cartella protetta
Aprire l’htaccess che risiede dentro la cartella protetta da password e in cima, prima di ogni riga scritta aggiungere i seguenti comandi:
|
1 2 |
Options +Indexes DirectoryIndex awstats.pl |
Salvare e caricare il file.
Seguendo questi 3 passi si ottiene la cartella delle statistiche protetta da password, accessibile dal web dopo aver inserito user e password nella maschera di acesso e la navigazione di Drupal intatta, eventuali aree protette agli utenti comprese.
Drupal è un Content Management Framework scritto in php che si appoggia su db sql.
Contenuto e stile sono distintamente divisi tra record sul database e file di cui è composto il framework.
Per effettuare il trasferimento del database non è necessario fare nulla se non esportare un file sql.
E’ però necessario fare una modifica ad un record per evitare che il processo di importazione si interrompa quando giunge in una determinata tabella.
Qual è il problema:
Il problema riguarda la tabella users
In sostanza, in fase di importazione il primo record inserito una volta creata una tabella è quello che ha uid = 0, ossia quello che per Drupal è l’utente anonimo, ma il primo valore accettato di default dalla tabella importata e appena creata è 1, quindi il record aggiorna automaticamente la chiave da 0 ad 1.
Quando si passa all’inserimento del record successivo però il processo incontra un campo uid dal valore 1, che è il primo utente creato dopo l’installazione, ed è il super amministratore del sistema.
Un record con uid = 1 però esiste già, quindi il processo si interrompe riportando l’errore “duplicate entry for primary key”.
Per ovviare a questo problema è necessaria preventivamente cambiare nella tabella users di origine il valore di uid = 0 in un numero diverso da zero, e non esistente, per assurdo diciamo 999 (difficile avere creato 999 utenti) evitando così lo shift della chiave primaria.
Una volta effettuato l’import (come vedremo proseguendo) dovremo cambiare, sia nella tabella importata sia in quella di origine l’uid cambiato di nuovo a 0
E’ possibile effettuare l’esportazione tramite l’interfaccia di phpmyadmin:
Dal menu orizzontale alto selezionare “Esporta”
Dalla pagina che raggiungiamo scegliamo il formato che ci interessa, nel nostro caso SQL
Nel caso il database fosse molto corposo possiamo decidere di comprimerlo in un file .zip o in un file .tar.gz
Ciò che otterremo sarà un file con tutte le query necessarie per riprodurre da qualche altra parte il database del nostro sito in drupal.
Conserviamo con cura una copia del file, e apriamo l’interfaccia phpmyadmin del nuovo server
Analogamente al comando esporta utilizzaremo la funzione “Importa”
E andremo a caricare il file .sql ( o compresso) che abbiamo salvato in precedenza.
Il processo può essere più o meno lungo a seconda delle dimensioni del nostro database.
A processo completato avremo una perfetta copia del nostro database, che abbiamo utilizzato fino a quel momento, ma sul database nuovo.
L’ultima modifica da fare è quella di aggiornare la tabella users modificando il valore della chiave primaria 999 al valore originario 0.
Ora la nostra copia è perfetta.
Da file vecchi a database nuovo
Il passaggio successivo consiste nel far puntare al sito che vogliamo trasferire il nuovo database sul nuovo server modificando il file settings.php
Il vantaggio di questa operazione sta nell’aggiornare il database che sarà definitivo sia nel tempo in cui materialmente trasferiremo i file via ftp da un server ad un altro, sia nel tempo in cui i dns si propagheranno per la rete, dopo averli cambiati.
Il file da modificare è quindi il file settings.php dentro la cartella sites/default dell’installazione di drupal
La riga che ci interessa è la 92, se non abbiamo mai modificato il file in precedenza.
$db_url = ‘mysql://nomeutente:password@ipserverdatabase/nomedeldatabase‘;
Dobbiamo cambiare il valore di ipserverdatabase scrivendo l’ip del server su cui abbiamo trasferito il database.
Dovesse essere necessario cambiamo anche nomeutente e password, sarebbe buona pratica mantenere lo stesso nome utente, e la stessa password tra i due server, in modo da non dover modificare nessun parametro se non quello dell’ip del database.
Modifichiamo e carichiamo il file. Dopo averlo caricato modifichiamo i suoi permessi in 0644.
A questo punto testiamo il sito inserendo un contenuto e verificando che la tabella node si aggiorni sul nuovo server.
Trasferimento dei file
Il passaggio successivo consiste nel trasferire materialmente tutti i file da un server all’altro via FTP.
Il processo può essere lungo specialmente per i contenuti multimediali che Drupal da solo può avere creato (tipo tutte le immagini di imagecache, se utilizzato).
Il penultimo passaggio consiste nell’assegnazione dei giusti permessi alle cartelle per il corretto funzionamento dei file.
Cambio dei permessi
Tutte le cartelle caricate, di default, non sono accessibili in scrittura.
Ci dobbiamo segnare il percorso di sistema e la directory temporanea che usiamo per gestire i file controllando la pagina “file system” nel backoffice del sito, all’url
admin/settings/file-system
Impostiamo quei percorsi con i permessi 0777 tramite filezilla.
NB la distribuzione dei permessi non influisce sul funzionamento del sito stesso ma solo sulla protezione da scritture/letture esterne e sulla creazione automatica delle immagini.
Se i file e il db sono collegati correttamente i dati dal database vengono estratti indipendentemente dai permessi.
Modifica dei dns
A questo punto non ci rimane che aggiornare i record dns per il dominio, attendere la propagazione e verificare il corretto funzionamento dei file trasferiti, o in alternativa aggiornare il nostro file host con ip e nome di dominio nuovi per verificare localmente che tutto funzioni a dovere.
Riporto un link a un sito contenente informazioni utili riguardanti l’utilizzo di Drupal.
http://sixrevisions.com/web-development/22-excellent-tips-for-new-drupal-developers/
Indicazioni dalla base:
- Installazione Creazione dei file e distribuzione dei permessi di scrittura
- Creazione primo profilo Quello che sarà l’utente principale per la gestione dei sito
- Creazione dei ruoli e dei permessi: Distribuzione di permessi per la gestione del sito
- Gestione degli errori e del white screen of death
- Gestione delle prestazione tramite la cache e il cron.php
Settaggi base del sito:
- url semplificate e riscritte
- compilazione delle informazioni base sul sito.
Temizzazione dei front:
- installazione di un nuovo tema
- concetti base riguardanti i temi Concetto di template, file in cui è diviso il tema (page, node blocco), sovrascrittura delle funzioni e delle variabili
- Mostrare il contenuto nel front tramite le viste Cos’è una vista (generatore di query trmaite interfaccia grafica), come stilizzare i campi stampati dalla query
- Customizzazione delle pagine non trovate e delle pagine di errore.
Creazione dei propri contenuti:
- spiegazione del concetto base di tipo di contenuto, cos’è cosa vuol dire e cosa è possibile creare tramite i campi peronalizzati.
- Utilizzo di un editor di testo per l’inserimento dei propri contenuti.
Nel nostro form creato con il modulo Webform per drupal aggiungere un campo testuale, chiamiamolo antispam, di tipo text field e impostiamolo con non obbligatorio (non spuntare la casella mandatory) e non includiamolo in email (non spuntare la casella email).
Aprire il foglio di stile del nostro tema e modifichiamolo per nascondere il campo alla vista degli utenti. In genere il codice necessario è
div#webform-component-antispam {display: none;}
N.B. antispam è il nome del nostro campo, e caratterizza sia le regole del foglio di stile, sia le regole di validazione del form, che vedremo più avanti, assicurarsi quindi di mantenere antispam o il nome che scegliamo per il campo in tutto il codice che copiamo da questi appunti.
Torniamo nella configurazione del nostro form e cerchiamo il gruppo di opzioni Webform advanced settings; all’interno di “Additional Validation” incolliamo
|
1 2 3 4 5 |
<?php if ($form_values['submitted_tree']['antispam'] != "") { form_set_error('submitted_tree][antispam', t('Failed attempt')); } ?> |
dove antispam è il nome del nostro campo aggiuntivo.
A questo punto il nostro form di contatto possiede un campo in più nascosto alla vista dell’utente, e che quindi l’utente non compila. Il controllo aggiuntivo fà si che se il campo è vuoto il form venga processato correttamente, in caso contrario (come succede quando sono i bot a inviare messaggi di spam) il form non passa la validazione, e non invia il messaggio.
Documento elenco scaricabile dei moduli, e relativa descrizione sul loro funzionamento, necessari per una installazione base di Drupal.
Sono elencati moduli base, moduli aggiuntivi per il seo, moduli per il backoffice, e moduli necessari in caso di registrazione utente autorizzata.
Allegato: moduli_drupal