Introduzione

Generalemente quando si parla di URL Brevi, in inglese Short URL, ci si riferisce ad alcune tecniche per modificare l'indirizzo delle proprie pagine web al fine di ridurne la lunghezza e renderlo più leggibile.

I motivi per utilizzare gli URL Brevi sono tanti e ancora oggetto di discussione, di conseguenza non li tratterò in questa guida. Dirò solo che normalmente lo si fa per indicizzare meglio il proprio sito e perchè gli utenti preferiscono link leggibili.

La riscrittura può essere parziale e completa, per quest'ultima si utilizza il modulo di apache mod_rewrite.

URL Brevi su Zikula

Zikula implementa di default un sistema per la riscrittura degli URL. Questo sistema prevede 3 tipi diversi di link:

• standard, senza alcuna riscrittura
• stile directory
• stile file

Nel corso di questa guida utilizzeremo il sistema stile directory per fare gli esempi, parleremo di quello stile file alla fine.

Per attivare gli URL brevi è sufficiente andare nel pannello di amministrazione -> Sistema -> Impostazioni e mettere Abilita gli URLs brevi sì. Ricordatevi però che se scegliete lo stile file o lo stile directory senza punto d'ingresso, dovete prima copiare il relativo file (shorturls.file.htaccess per lo stile file e shorturls.directory.htaccess per lo stile directory) dalla cartella docs/ alla root del vostro sito rinominandolo il .htaccess (sì, ci va il punto davanti!)

Attenzione:  duplicare le pagine (cioè avere 2 indirizzi diversi che puntano alla stessa pagina) è dannoso per l'indicizzazione! Se il vostro sito è online già da tempo, ed è già stato indicizzato dai motori di ricerca, attivando gli URL brevi potreste ottenere un danno al posto di un beneficio! Generalmente si consiglia di scegliere uno stile di URL brevi e di attivarlo quando si pubblica il sito la prima volta, per poi non cambiarlo più.

Vediamo ora come funzionano gli URL brevi (solo per informazione, per utilizzarli vi basta attivarli). Questo è un indirizzo come si presenta normalmente:

Riscrittura dell'URL senza mod_rewrite

Tramite una riscrittura parziale, vale a dire che non utilizzi mod_rewrite, possiamo ottenere un'indirizzo di questo tipo: 

Abbiamo così un indirizzo più breve (la differenza sarebbe stata molto maggiore se il primo indirizzo fosse stato davvero lungo) e sicuramente più leggibile.

Il meccanismo che ci mermette di implementare la riscrittura parziale è molto semplice. Infatti il webserver carica ed esegue il file index.php, il quale recupera i parametri successivi semplicemente dall'header (la variabile è $ _SERVER['REQUEST_URI'] e la potete vedere utilizzando phpinfo() ). A questo punto il sistema sa che in che ordine i parametri dovrebbero essere, quindi Zikula sa anche che pagina è stata richiesta.

Questo meccanismo permette ovviamente di passare anche parametri personalizzati, ad esempio se vogliamo caricare un forum con id=2 il link sarà simile a questo:

Nota: l'URL rewriting utilizza ":" per passare i parametri, non potete quindi utilizzare variabili come "index.php?variable=filter:3" (ricordatevelo se doveste usare pagesetter e il suo sistema di filtri)

Riscrittura dell'URL con mod_rewrite

Come molti di voi già sapranno, mod_rewrite è un modulo di Apache molto utile che permette, tra le altre cose, di riscrivere gli URL. Grazie ad esso potremo quindi effettuare una riscrittura completa dell'URL e migliorare gli esempi di prima rimuovendo index.php. Come avrete sicuramente notato tutti i link che abbiamo visto contenevano la dicitura index.php, tuttavia quest'informazione è implicita in quanto tutte le pagina di Zikula passano da index.php, ripeterla è inutile.

Utilizzando mod_rewrite possiamo ottenere il seguente risultato:

Nota: fate attenzione, se una delle vostre immagini dovesse essere scritta così <img src="test.png">, caricando il modulo /MyModule/main, il browser sichiederà l'immagine "/MyModule/main/test.png". Per risolvere potete utilizzare l'indirizzo completo dell'immagine o effettuare un redirect di questo tipo "/*/*/*.(jpg | png | gif)" to "$ 3. (Jpg | png | gif)."

Riscrittura dell'URL stile file

Il metodo di rewrite classico, già utilizzato nelle precedenti versioni di PostNuke, mostrerà link di questo tipo:

Come potete vedere il link è composto da una serie di parole (il nome del modulo e i parametri) separate da trattini. Considerate però che questa versione fa un uso maggiore delle espressioni regolari per riscrivere il link e potrebbe aumentare il carico sul vostro server.

Nota: la parola module potrebbe essere implicita come la parola index.php negli esempi precedenti, viene mantenuta per compatibilità con i link di vecchio stile.

Riscrittura dell'URL personalizzata

Zikula permette infine di personalizzare la riscrittura per un modulo in particolare. Per farlo dovete creare le funzioni encodeurl e decodeurl nel file pnuserapi del vostro modulo. La prima deve prendere in input le informazioni necessarie e restituire in output il link personalizzato, mentre la seconda deve effettuare il passo inverso.

Potete trovare un esempio di questo metodo nel modulo Pagine / Pages.

Con questo metodo potete:

• mettere delle keywords nell'indirizzo;
• avere diversi tipi di link per lo stesso modulo;

Inoltre, se un link non è conforme al vostro standard, potete in qualsiasi momento effettuare un redirect 301.

Questa pagina è basata sull'articolo URL rewriting on PostNuke 0.8 scritto da mumuri. 

Vediamo ora alcuni consigli su come migliorare la sicurezza della propria installazione.

Aggiornare sempre all'ultima versione

Non mi stancherò mai di ripeterlo, il miglior modo per proteggere la vostra installazione di Zikula è tenerla sempre aggiornata. Eventuali problemi di sicurezza scoperti vengono infatti corretti tramite gli aggiornamenti. Non aggiornare potrebbe significare lasciare il proprio sistema esposto a rischi.

Lo stesso discorso vale per i moduli che avete installato.

Migliorare la configurazione

Zikula è distribuito con uno script di installazione in grado di configurare il sistema sulla maggior parte degli host. Tuttavia vi sono alcune precauzioni che si possono prendere solo a mano e, se il vostro server lo permette, è consigliabile adottarle.

• spostare la cartella pnTemp fuori dalla root del server: di default la cartella pnTemp si trova nella web root del server, sullo stesso livello delle cartelle themes, modules ecc. Per ragioni di sicurezza sarebbe però meglio non avere cartelle scrivibili accessibili direttamente dal web, quindi si consiglia di spostare la cartella pnTemp fuori dalla web root del vostro sito. Se possibile spostate quindi la cartella pnTemp (in modo che non sia ne in public_html ne in www) e mettete il path completo alla nuova posizione nel file config/config.php alla riga $PNConfig['System']['temp'];
• configurazione di PHP: è possibile migliorare la sicurezza modificando alcune impostazioni di PHP. Il modulo Informazioni sul Sistema, effettuando un'analisi della vostra installazione, è in grado di dirvi quali impostazioni sia meglio modificare;
• controllare i permessi: se possibile non dovrebbero essere possibile accedere dal browser ad alcuna cartella con permessi 777. Tutti i file dovrebbero avere come permessi 644 o 444, mentre tutte le cartelle dovrebbero essere 755;

Queste sono delle indicazioni generali, ciò non toglie che potreste avere la necessità di avere una cartella scrivibile accessibile direttamente. Considerate però che normalmente tutti i moduli che necessitano di una cartella in scrittura, anche quelli di terze parti, permettono di posizionarla all'esterno della web root.

Vediamo ora alcuni consigli su come migliorare le performance di Zikula. Ricordate però che anche la configurazione del server gioca un ruolo fondamentale in questo ambito.

Aggiornate all'ultima versione di Zikula

Si raccomanda sempre di avere Zikula aggiornato all'ultima versione. Il motivo principale è ovviamente la sicurezza, tuttavia gli aggiornamenti contengono spesso anche delle revisioni del ccodice che può migliorare le performance.

Abilitate il caching

Un grande aiuto per migliorare le performance del sito ci viene dai sistemi di caching integrati di Zikula. Questo è sicuramente il miglior modo per aumentarela velocità delle pagine e diminuire il carico sul server.

Il caching è meglio trattato nella prossima sezione, cercate li maggiori informazioni.

Usate Alternative PHP-Cache

Un altro metodo per migliorare le prestazioni è abilitare un terzo sistema di caching, ma a livello di interprete PHP. Cito una descrzione di APC da html.it

Installate l'estensione ADOdb

L'Estensione ADOdb aumenta fino al 100% la velocità della libreria ADOdb sostituendo alcune parti di PHP con codice C.

Può essere installata sia su Windows che su Linux e funziona sia con PHP 4 sia con PHP 5.

Disattivate Statistiche e Referrers

I moduli Statistiche e Referrers, che lavorano abbinati, effettuano query al database e utilizzano risorse ad ogni pagina vista. Se non strettamente necessari si consiglia di disabilitarli, soprattutto considerando che esistono servizi esterni decisamente migliori, come Awstats e Google Analytics (tuttavia quest'ultimo alleggerisce il server ma aggiunge codice javascript).

Riducete il numero di blocchi

Un altro elemento che influenza il tempo di caricameno di ogni pagina sono i blocchi. Se avete dei blocchi inattivi che non pensate di riutilizzare in futuro rimuoveteli, infatti ad ogni pagina vista Zikula li deve prendere in considerazione per decidere se vadano mostrati o meno.

Ottimizzate MySQL

Si consiglia di mantenere ottimizzato il database. Esistono infatti dei tool che permettono, un pò come la deframmentazione di Windows, di ottimizzare tutte le tabelle. Se avete problemi di lentezza si consiglia di utilizzarli regolarmente, potrebbero migliorare la velocità delle query.

Moduli di terze parti

Alcuni moduli di terze parti, soprattutto quelli fatti per gestire grandi quantità di dati, implementano delle funzioni di ottimizzazione. PNphpBB2 ne è un esempio.

Introduzione

Il caching è una funzione molto utile che permette di generare dei file HTML contenenti le pagine complete in modo da evitare di generarle nuovamente alle successive richieste. Questo riduce drasticamente il numero di query al database e il tempo necessario a caricare la pagina.

Normalmente si consiglia di lasciarlo disabilitato, salvo sia proprio necessario per alleggerire il server. Ovviamente a tutti piacerebbe usare al meglio il sistema di caching, ma perchè complicarsi la vita quando non strettamente necessario?

In questa pagina analizzeremo il sistema caching di Zikula, ne discuteremo pro e contro e vedremo come configurarlo.

Due livelli di caching: pnRender e Xanthia

In Zikula il caching è implementato su due livelli: pnRender e Xanthia.

Il caching a livello di pnRender è un caching parziale, viene infatti memorizzata solo una parte della pagina, quella gestita dal modulo e dai blocchi. Questo è il livello di caching principale di Zikula e normalmente presenta solo leggeri effetti collaterali, dipendenti dai moduli che si stanno utilizzando.

Il caching a livello di Xanthia è invece detto full page caching, in quanto tutta la pagina viene memorizzata in cache. Salvo non siate veramente disperati per il carico sul vostro server, si sconsiglia di abilitare questa opzione in quanto vi sono degli effetti collaterali importanti. In questo caso il codice del modulo non viene mai eseguito (tranne quando si rigenera la pagina) e vi possono essere delle conseguenze più o meno gravi (pensate ad esempio al conteggio delle letture di una pagina, sarebbe completamente falsata).

Ovviamente il secondo livello di Xanthia è disponibile solamente se state utilizzando un tema Xanthia.

Perchè è disabilitato di default?

Di default il caching delle pagine è disabilitato in quanto, sebbene il sistema di caching sia alla base del framework, perchè funzioni correttamente è necessario che sia utilizzato correttamente dagli autori dei moduli. In caso contrario possono verificarsi degli effetti collaterali di vario tipo.

Dato che, durante il processo di personalizzazione, vengono mediamente installati molti moduli di terza parte per cui il team di Zikula non può garantire il corretto funzionamento del caching, di default è disabilitato. Si lascia quindi all'amministratore l'analisi e il testing del caching con quella particolare configurazione di moduli.

Inoltre il sistema di caching ha anche dei contro. Permette infatti di salvare tempo e calcoli a discapito della memoria su disco. Infatti i file di cache devono essere salvati sul disco e, per siti molto grandi, possono essere davvero tanti.

Quali sono i rischi effettuando caching

Se l'autore del modulo non ha fatto nulla affinchè il caching funzioni è probabile che quel modulo presenti dei problemi abilitandolo. E' infatti importante assicurarsi che tutti i controlli (es. permessi, errori ecc.) vengano effettuati prima che intervenga il sistema di caching. In caso contrario si rischia di:

• limitare l'accesso ad una pagina: se la pagina viene generata quando fa la richiesta un utente che non vi ha accesso, tutti gli utenti successivi non la vedranno, anche se loro dovessero essere abilitati;
• dare accesso ad una pagina: può accadere anche il contrario, cioè che la pagina venga generata da un utente che ha i permessi e rimanga visibile a tutti gli utenti;
• esporre dati personali: pensate ad esempio ad una pagina con un form che viene auto compilato con i dati dell'utente registrato, tutti gli utenti successivi potrebbero vedere i suoi dati;
• non considerare gli errori: se non si controlla che i dati siano correttamente generati, si rischia che un errore singolo (es. timeout del database) venga visualizzato per tutta la durata del file di cache;

Ribadisco che questi sono i rischi di un modulo mal progettato, non i rischi di tutti i moduli. Sono cose da tenere in considerazione, e possibilmente testare, soprattutto quando si abilita il caching con tanti moduli di terze parti installati.

Qual è una buona configurazione di caching

Non esiste una configurazione perfetta, anche perchè se esistesse il caching non sarebbe ne disabilitabile ne configurabile (che bisogno ci sarebbe di configurare o disabilitare un sistema perfetto?). Si può invece parlare di una buona configurazione, che si adatti alla vostra situazione.

Come abbiamo già detto, salvo abbiate grossi problemi di risorse, lasciare il caching di Xanthia (è quello che si può abilitare nella sezione Temi) disabilitato.

Per quanto riguarda pnRender invece potete abilitarlo dalla sezione pnRender, nel pannello di amministrazione. La durata della cache dovete deciderla voi in base al sito che state gestendo. In teoria, se ogni modulo gestisse la cache in modo perfetto, si potrebbe utilizzare 3600 secondi per tutti i siti. Sarebbe infatti sufficiente che il modulo eliminasse il file di cache ogni volta che il contenuto di quella pagina viene modificato. Dato però che non tutti gli autori sono così scrupolosi nello scrivere i moduli, è necessario trovare un buon compromesso tra prestazioni e funzionalità.

I valori che mediamente si consiglia (non sono valori rilasciati ufficialmente, sono l'insieme dei feedback della comunità internazionale n.d.a.) sono i seguenti:

• 10 secondi, se è un sito che viene aggiornato continuamente, come un forum;
  
• 3600 secondi, se invece è un sito che contiene prevalentemente pagine statiche che vengono aggiornate raramente;
  

Vi sembra poco?

Considerate che se ogni pagina viene richiesta 1 volta al minuto, del caching non ve ne fate nulla. Il caching è utile quando le stesse pagine vengono richieste più e più volte al minuto.

Prendiamo come esempio un forum. Mettendo 10 secondi l'utente vede i post praticamente in tempo reale, tuttavia se una pagina viene richiesta 2 volte al secondo, impostando il caching a 10 secondi per 19 volte risparmiate al vostro server molti calcoli e query. Nota: quello del forum è solo un esempio, in realtà il caching non può essere abilitato per pnForum.

Considerate che mettere valori di caching troppo alti è inutile. Ipotizzando di ricevere 2 richieste della stessa pagina al secondo, abbiamo che:

• senza caching generemmo la pagina 7200 volte all'ora
• con il caching di 10 secondi, genereremmo la pagina 360 volte all'ora
• con il caching di 60 secondi, genereremmo la pagina 60 volte all'ora
• con il caching di 60 minuti, genereremmo la pagina una volta all'ora

Vedete quindi come con un caching di 10 secondi ci risparmieremmo 6840 pagine generate, mentre con il caching di 3600 secondi ci risparmieremmo solamente 359 pagine generate in meno.

Vi sembra tanto?

Il precedente calcolo potrebbe portarvi a pensare che allora è inutile mettere 3600 come durata della cache. Considerate però che se le pagine in questione sono tante (es. 100) ed ognuna viene richiesta 2 volte al secondo... allora il risparmio diventa di 35900 pagine in meno all'ora. Non male no?

Infine vi è anche da considerare che rigenerare continuamente i file di cache significa continuare a cancellare e ricreare dei file. Talvolta questo comportamento è malvisto dai servizi di hosting, impostare un valore di caching medio/alto serve anche a diminuire l'utilizzo dell'hard disk in scrittura.