RealURL facile: parte 1

La gente molto spesso lamenta che RealURL sia difficile da configurare. Credo che questo accada perchè il manuale di RealURL è scritto come una guida di riferimento, non come un tutorial.
Per questo motivo non c'è nulla da cui iniziare per un principiante. Le ultime versioni di RealURL includono una configurazione automatica, che va bene per siti web semplici. E' vero anche che non è abbastanza flessibile. Una configurazione manuale vincerebbe sempre su una automatica. Questo articolo fornisce una semplice guida per una configurazione manuale di RealURL. Non è breve,  quindi prendiamo del tempo per leggerlo.

L'intera guida è divisa in diverse parti. La prima parte descrive la configurazione in generale. Le altre parti descriveranno i dettagli, i tip&tricks e le best practices.

Basi

Questa sezione copre i principi generali di RealURL.

RealURLed URL

Prima di partire con la configurazione, deve essere chiaro di che parti sono costituiti gli URLs di RealURL.

Un tipico URL di RealURL consiste di diversi segmenti:


I segmenti sono (in ordine di apparizione):

• preVars
  Sono anteposti al percorso della pagina. Di solito si tratta di identificatori di lingua. Non dovrebbero essere troppi lunghi.
• Page path
  Questo è un percorso che porta alla pagina. E' creato attraversando un albero di pagine dalla radice del sito web sino alla pagina di destinazione. Ci sono diversi campi che possono essere utilizzati per creare i segmenti. Di solito si tratta dei titolo della pagina, dell'alias, del sottotitolo e di un campo speciale di RealURL chiamato "Path segment".
• fixedPostVars
  Sono parametri non prefissati sulla pagina. Sono molto simili al preVars ma vanno dopo la pagina. Di solito sono impostati soltanto per pagine specifiche e non per l'intero sito.
• postVars
  Sono parametri prefissati sulla pagina. Per esempio, tx_ttnews[tt_news]=5 può essere convertito in /news/test-news-item/. Qui “news” identifica tx_ttnews[tt_news] e il 5 è rimpiazzato dal titolo della news. 

Ogni segmento (eccetto il page path) può avere diverse variabili.

Basi di configurazione

Normalmente la configurazione di RealURL è conservata in un file separato. Questo file è di solito incluso in typo3conf/localconf.php.

La configurazione di RealURL è un array PHP annidato. La configurazione è creata per un singolo sito web. A rigor di logica appare come:
Ci sono due tipi di inserimenti qui. Un nome di dominio può puntare ad un altro nome di dominio o ad un array di configurazione.
Se un nome di dominio punta ad un altro nome di dominio, RealURL prenderà la configurazione del dominio puntato. Possono esistere diversi puntatori nella catena.
Se un nome di dominio punta ad un array, questo è la sua configurazione. Approfondiremo a breve.
Se c'è solo un dominio, non c'è bisogno di specificare il suo nome. L'intera configurazione allora può sembrare qualcosa tipo:
Questo caso è valido anche se domain.com è un alias di www.domain.com.

L'array di configurazione per ogni dominio (or per _DEFAULT) consiste in subarray, chiamati sezioni di configurazione.

Sezioni di configurazione

Esistono sei sezioni di configurazione. Nessuna di loro è obbligatoria ma almeno due sono di solito utilizzate. Di seguito un rapido sguardo alle sezioni:

• init
  Questa sezione descrive le opzioni generali di RealURL, come le cache, i valori di ritorno degli URL vuoti e delle altre opzioni.
• preVars
  Questa sezione definisci le preVars (guarda l'esempio di URL sopra!). Molto semplice.
• fixedPostVars
  Questa sezione definisce le fixedPostVars.
• postVarSets
  Questa sezione definisce le postVarsSets. Questa è la parte di configurazione più delicata.
• pagePath
  Questa sezione è di solito una sezione copia/incolla. Non cambia molto fra i diversi server. Tuttavia ha un parametro (rootpage_id), che è di fondamentale importanza nella configurazione multidominio.
• fileName
  Tale sezione permette di terminare gli URLs con qualcosa di simile a "rss.xml" o "print.html". Anche questa è in linea di massima una sezione copia/incolla.

Creare la sezione init

La sezione init normalmente contiene le direttive della configurazione della cache ed alcune altre utili opzioni. Di seguito un breve elenco che si dovrebbe avere nella propria configurazione:

• 'enableCHashCache' => true
  Utilizziamo questa se il sito web non usa nessuna estensione con parametri  nell'URL. Dettagli circa cHash possono trovarsi qui e qui.
• 'appendMissingSlash' => 'ifNotFile'
  Questa direttiva aggiunge uno slasj alla fine dell'URL. Appare soltanto più gradevole.
• 'enableUrlDecodeCache' => true
  Permette di utilizare la veloce cache basata sul database quando un utente visita una pagina. E' un enorme miglioramento di performance rispetto a quando la cache è disabilitata.
• 'enableUrlEncodeCache' => false
  Come sopra ma per la codifica. E' utilizzata quando si creano i link. Non c'è alcun motivo di disabilitare questa direttiva come quella precedente.

Questo elenco non è completo. Possiamo trovare altre direttive nel manuale di RealURL.

Creare la sezione prevars

La sezione consiste di una o più parti. Ogni parte è essa stessa un array e definisce una singola preVar. Esempio:

In questo esempio, preVar è associata con il parametro di URL "L". valueMap dice che L=0 è mappato con /en/, L=1 è mappato con /de/. noMatch dice che qualsiasi altro valore di L sarà ignorato silenziosamente.

E' possibile specificare anche valori di default o fare altre conversioni. Per i dettagli si incoraggia il lettore a guardare il manuale di RealUrl.

Creare la sezione fixedPostVars

Le fixedPostVars sono molti simili alle preVars. Ci sono solo due differenze:

• le fixedPostVars sono piazzate nell'URL dopo il percorso della pagina.
• le fixedPostVars devono avere o un page id o una keyword _DEFAULT (per tutte le pagine).

Guardiamo l'esempio:   C'è più di un array contenitore attorno alla vera definizione della fixedPostVar. Questo array contenitore dice che la pagina con id 35 ha questa fixedPostVar. Quindi la fixedPostVar "no-comments" non sarà applicata alle altre pagine (a meno che non sia aggiunta anche per loro). C'è anche un 'noMatch' per saltare completamente questa variabile quando non ha senso averla.
Nel caso sia necessario avere più di una fixedPostVar su questa pagina, questa seguirà la prima, come si può vedere: Le fixedPostVars appariranno nell'ordine definito. E' importante pensare bene all'ordine e mantenerlo una volta che sia definito o la decodifica non sarà fatta in maniera appropriata.

Creare i set di postVars

I postVarsSets assomigliano alle fixedPostVars ma hanno in più dei prefissi che identificano una postVar. Ciò permette di inserire delle postVars in qualsiasi ordine all'interno dell'URL. Permette anche di avere un set flessibile di postVars.

Una postVar nell'URL può in realtà definire diversi parametri reali GET. Per esempio:

Ora immaginiamo un URL non codificato come questo:

domain.com/index.php

L'URL codificato apparirà come:

domain.com/page/path/myparam/12/34/

E' anche possibile convertire i numeri in stringhe se si riferiscono a tabelle di database. Si può inoltre utilizzare codice Php per mappare parametri reali GET in parametri codificati e viceversa. Il sistema è estremamente flessibile e permette di fare quasi qualsiasi cosa!

La sezione pagePath

La sezione pagePath è di solito utilizzata per ampliare ulteriormente RealURL. Di default RealURL crea URL come questo:

domain.com/35/myparam/12/34/

Per rimpiazzare il page id (35 nell'esempio corrente) con un percorso reale alla pagina, deve essere inserito il seguente contenuto nella sezione pagePath:
Esistono altre direttive. La più importante di loro è rootpage_id. Questa direttiva punta alla pagina che è radice (home page) del sito web corrente. Deve essere impostata per configurazioni multidominio e si raccomanda di impostarla anche in configurazioni monodominio (altrimenti RealURL dovrà cercarla). Dimenticare questa direttiva nelle configurazioni multidominio porta ad un comportamento non corretto di RealURL!

Sezione fileName

Saltare questa sezione nella configurazione non è pericoloso. In genere non è necessaria a meno non si voglia creare nell'URL accattivanti parti finali dei nomi file.

Conclusione

In questo articolo abbiamo passato in rassegna la configurazione di RealURL. Nel prossimo articolo mostreremo come rendere questa configurazione efficace. L'articolo mostrerà alcuni tips&tricks che non sono ovvi leggendo il manuale e che si dovrebbe conoscere. Allora, guardate questo sito per il prossimo articolo! _____________

Questo articolo è una traduzione dell'articolo RealURL made easy: part 1 scritto da Dmitry Dulepov sul suo blog personale.

La traduzione è stata autorizzata dall'autore ed essa come l'articolo originale non ricade sotto licenza Creative Commons al contrario della gran parte dei contenuti di My Geek Memos.