Uno degli aspetti più importanti quando sviluppiamo un sito web è la gestione dei path assoluti o relativi.
Per chi non lo sapesse, il path di un URL può essere principalmente di due tipi:
path assoluti
/home/pagina.html
oppure
http://ilmiosito.it//home/pagina.html
path relativi
home/pagina.html
oppure
../home/pagina.html
Nessuno dei due sistemi è migliore dell'altro, dipende da ciò che dobbiamo fare. In ogni caso quello che probabilmente ci serve è uno strumento in grado di dirci dove si trova la nostra pagina e qual'è il suo URL effettivo. Si potrebbe pensare che queste informazioni siano sempre disponibili, ma non è sempre così. Consideriamo ad esempio un sito sviluppato in locale, lavorando su un server Apache (su Windows) che ospita tutti i nostri progetti
C:\Applicazioni\xampp\htdocs\sito_1\index.html
C:\Applicazioni\xampp\htdocs\sito_1\news\notizie.html
...
C:\Applicazioni\xampp\htdocs\sito_2\index.html
ecc...
in questo caso i nostri siti non si trovano sotto la root del server. Ad esempio, l'URL per passare dalla pagina notizie.html alla index.html del primo sito sarà qualcosa del tipo
/../sito_1/index.html (percorso relativo)
/sito_1/index.html (percorso assoluto)
Fin qui tutto bene, abbiamo due modi di raggiungere la index.html, per cui le due scelte sono tutto sommato equivalenti. Le cose cambiamo quando andremo ad installare il sito su un server remoto. In tal caso potrebbe capitare di deployare il sito_1 all'interno di un percorso del tipo
/opt/apache2/htdocs/index.html
/opt/apache2/htdocs/news/notizie.html
ecc...
In questo caso il modo di passare dalla pagina notizie.html alla index.html del secondo sito sarà in generale diverso, ad esempio
/../index.html (percorso relativo)
/index.html (percorso assoluto)
Questo è chiaramente un problema. Se in locale abbiamo usato degli URL scritti in forma esplicita, usando percorsi del tipo /../sito_1/index.html (relativo) oppure /sito_1/index.html (assoluto), avremo comunque delle seccature. La causa del problema è la differente struttura dell'ambiente di sviluppo (locale) rispetto a quello di produzione (remoto). Problemi di questo tipo si possono risolvere in vari modi, principalmente organizzando accuratamente gli ambienti di lavoro, oppure usando alcune best practices per la sintassi dei vari URL. Ma cosa fare se non possiamo (o vogliamo) riorganizzare la struttura degli ambienti di lavoro, o se è troppo tardi per intervenire sull'architettura del progetto? In questo caso possono tornarci utili alcune funzioni PHP, che permettono di sapere a run-time qual'è URL effettivo di una pagina.
Consideriamo la funzione
function getBaseURL() {
if ( (isset($_SERVER["HTTPS"])) && (
$_SERVER["HTTPS"] == "on") ) $base_url = "https://" ;
else $base_url = 'http://' ;
if ($_SERVER["SERVER_PORT"] != "80") {
$base_url .= $_SERVER["SERVER_NAME"].
":".$_SERVER["SERVER_PORT"] ;
} else {
$base_url .= $_SERVER["SERVER_NAME"] ;
}
return $base_url ;
}
la funzione sfrutta l'array super-global $_SERVER per capire il tipo di protocollo utilizzato, la porta del server e il nome del server. Se ci serve anche l'URI completo di una pagina basterà usare la funzione
unction getCurrentPageURL() {
return getBaseURL().$_SERVER["REQUEST_URI"];
}
in questo modo avremo sempre a disposizione il valore dell'URL effettivo di una pagina, indipendentemente dal fatto che il codice PHP stia girando in locale o in remoto. Ciò permette di memorizzare l'URL all'interno di una variabile PHP e costruire tutti i percorsi in modo dinamico, a run-time, tramite codice del tipo
$root= getBaseURL() ;
include $root.'include/display_header.php' ;
Come dicevamo prima, si tratta di una buona soluzione per mettere una pezza su un sito già avviato senza stravolgere l'intera struttura. Se invece stiamo preparando il design di un sito ex-novo allora possiamo pensare anche a soluzioni più raffinate.
