Uno dei problemi che più spesso si incontrano nel progettare un sito web basato su templates è specificare il corretto percorso di immagini e links e fare in modo che funzionino su tutte le pagine.
Un template potrebbe infatti essere stato progettato per essere utilizzato con URL posti al suo stesso livello, ma non presentare collegamenti corretti ad immagini e altre risorse quando l'URI che ne fa uso è posto ad un livello differente, come ad esempio in una "sottocartella" della gerarchia degli indirizzi del sito.
Alcuni sono soliti risolvere questo problema specificando "link virtuali" (ad esempio "/images/structure/top.png") che in teoria dovrebbero funzionare qualunque sia l'URI della pagina che li contiene.
Nella pratica, ciò può causare dei problemi. Infatti, l'utilizzo di link virtuali potrebbe rendere molto difficile modificare un template di una pagina con un editor grafico, mostrando al contempo le sue immagini, senza utilizzare un web server locale per i test.
Ma soprattutto la stessa pagina potrebbe essere richiamata in modi differenti, come nei seguenti esempi:
- http://www.wedgefish.org/webs/myblog/articles/myarticle/
- http://www.wedgefish.org/it/webs/myblog/articles/myarticle/
- http://www.mywedgeblog.org/articles/myarticle/
- http://www.mywedgeblog.org/it/articles/myarticle/
Tutti questi URI corrispondono alla stessa risorsa: il primo ed il secondo specificano l'URI come facente parte di un sottosito del portale principale www.wedgefish.org, il terzo richiama direttamente l'URI dal dominio del sito cui appartiene, restituendo la pagina nella lingua del browser dell'utilizzatore o una traduzione alternativa disponibile, mentre il quarto specifica esplicitamente che deve essere restituita la versione italiana della pagina.
Un link virtuale sarebbe in grado di funzionare solo nel terzo caso. Quindi è necessario che tutti i links nel template vengano riscritti come "link relativi", ad esempio "../../images/structure/top.png", in modo che funzionino qualunque sia l'URI della pagina.
Fortunatamente questo viene svolto automaticamente da Wedgefish al momento di restituire la pagina al browser: tutti i links contenuti nel template, validi al livello nel filesystem al quale si trova lo stesso, vengono infatti sostituiti da una chiamata alla funzione wos_build_relative_url, che provvede a riscriverli per fare in modo che puntino alla stessa risorsa, anche se l'URL della pagina corrente si trova ad un livello differente.
Un esempio chiarirà meglio il funzionamento di questa tecnica: poniamo che il template si trovi in "templates/berryblog/views/webpage.html" e che contenga un link "images/layout/top.jpg" (la risorsa corrispondente si troverà in "templates/berryblog/views/images/layout/top.jpg").
Il template viene ora utilizzato nella pagina "articles/myarticle/". Nella pagina inviata al browser, il link verrà quindi riscritto automaticamente come "../../images/layout/top.jpg".
Spesso i link da visualizzare sulla pagina sono generati dal controller. È il caso di un elenco di links ad altre pagine, ottenuti interrogando il WODBMS e visualizzati dinamicamente.
In questo caso, il controller può riscrivere tali links utilizzando la funzione wos_get_relative_url prima di inviarli alla view.
Può risultare talvolta noioso dover specificare tale istruzione per ogni variabile contenente URL che deve essere passata alla view: è possibile quindi chiamare la funzione wos_auto_relative_url, all'inizio del controller, per fare in modo che tutti i campi di nome "wos_url" con tutti i loro indici vengano automaticamente riscritti nel momento in cui vengono restituiti dal WODBMS al controller stesso, in modo da poterli poi passare direttamente alla view senza dover eseguire wos_get_relative_url su ciascuno di essi. Tale funzione va comunque utilizzata con attenzione, poiché l'impostazione resterà attiva anche nel resto del controller ed in eventuali script che dovessero venire inclusi da quest'ultimo, come ad esempio una barra di menu (verrà comunque disabilitata prima delle successive richieste).
La risoluzione automatica dei link funziona anche sui collegamenti statici contenuti nei campi HTML memorizzati nel WODBMS: è sufficiente che tutti i link vengano sempre specificati come relativi alla cartella del sito (ad esempio "images/layout/top.jpg"). Ogni volta che verrà interrogato il WODBMS (ad esempio, con le funzioni wos_query_items o wos_get_item), tutti i collegamenti (contenuti nelle proprietà HREF, SRC, ACTION e BACKGROUND dei tags) che si trovano all'interno di campi di tipo HTML verranno automaticamente riscritti come link relativi in maniera da puntare alle stesse risorse, qualunque sia l'URI che è stato dato alla pagina che li rappresenta.
Talvolta, tale comportamento può non essere desiderato, ad esempio quando il contenuto di un campo HTML deve essere restituito senza essere alterato, come in un editor di item. In questo caso, è sufficiente passare il flag WOS_NO_HTML_REWRITE alla funzione wos_query_items (o alla funzione utilizzata per interrogare il WODBMS) per fare in modo che i link non vengano riscritti.
In definitiva, la funzione di risoluzione automatica dei link incorporata in Wedgefish costituisce un valido aiuto per tutti i webmaster che necessitano di riutilizzare la stessa grafica per molte pagine del loro sito, senza per questo dover adattare i link alle varie risorse ai vari indirizzi delle loro pagine.