Hoping some of you PHP ninjas can shed some light on this.
I’m currently working between localhost and a remote web server.
What I’m trying to do if possible is set a server independent base url for
my image, css, js directories.
What I have in mind is to set something like:
$baseURL = $_SERVER[‘SERVER_NAME’];
Then I can just reference the aforementioned resources using the variable.
My thinking is that on localhost, the baseURL variable will return well…
localhost and on the remote server, it will return something like mysite.com.
So in a nutshell, I won’t need to maintain a set of definitions for localhost and
another for the remote server.
My main question is, is this even good practice? I’ve done a bit of research and
have come across articles that mention possible security issues but they all fall
short of outright condemning this practice.
I’d greatly appreciate your opinion on this.
Also if you can shed some light on how you’d approach this problem, I’d be much
obliged, I’m a PHP noob here trying to bring myself up to speed as fast as possible.
Yeah, that’s really the best way to do it. Some server configurations may not support the SERVER_NAME var, but I’d imagine they are few and far between.
Good to know I need to watch out for “gotchas” on subdomains. I’ll look for a
workaround for this. As it stands, I’m using mainly subdirectories for each of
my site’s categories with only two subdomains, one for an online store and the
other for a tutorial wiki of sorts.
The server config at my current webhost seems to support this variable, I’m pretty
sure it’s running PHP 5 and latest Apache with support for 'Nix and windows. I’m
able to able to customize both php.ini and .htaccess. It’s good to know that this is
something I’ll need to look out for if I decide to change hosts in future.
I would estimate probably 99.9999% of the *nix servers – I can’t speak for the Win servers – out there support the $_SERVER[‘SERVER_NAME’]; variable. I can’t imagine why a sysadmin would disable it. I just wanted to make you aware of the possibility that some server’s “may” not support it.
The downside I found with using SERVER_NAME is that on NGiNX, SERVER_NAME contains the main server name, even if an alias is accessed, i.e., I have you have a virtualdomain [noparse]www.example.com[/noparse] with alias [noparse]example.com[/noparse] and you access [noparse]example.com[/noparse], $_SERVER[‘SERVER_NAME’] will report [noparse]www.example.com[/noparse]. Apache handles SERVER_NAME as you would expect though (i.e. reports the accessed host).
I’ve found that $_SERVER[‘HTTP_HOST’] instead of $_SERVER[‘SERVER_NAME’] works correctly for both Apache and NGiNX.
I would estimate probably 99.9999% of the *nix servers – I can’t speak for the Win
servers – out there support the $_SERVER[‘SERVER_NAME’]; variable. I can’t imagine
why a sysadmin would disable it.
Me neither… Still it has been good to know about these gotchas though. Props.
Interesting approach, thanks for your response. Your point about about sending less
chars to the client is with merit, especially for large documents where the extra code
that an absolute URL would necessitate could add up. Gotta shave off bytes and kb’s
wherever possible right?.
I’m a bit confused though about the url that would be generated and the “portability”
henceforth of each page/article so hoping you can elaborate on your suggestion a bit.
Unless I’ve got it totally confused by referencing resources using paths like:
img src=“/media/images/example.gif” link href=“/css/themes/example.css”
would this not create URLs that are relative to the doc that references the resource?
This will work on a “flat” site but on one with subdirectories, where the resources are
kept in a central place, would this not create broken links? It would mean that I would
need to change the URL path for each of the docs in the subdirectories so that the links
are relative to the doc/article/page in question. I could just have this twisted!
The reason I’m opting for absolute URL paths for resources like images, javascripts,
stylesheets etc is mainly for maintenance and portability reasons. I am also going
to implement a data feed of sorts on most pages that will pull article snippets from
various locations on the site and I’m thinking by using relative paths for images and
actual links (<a href=“”></a> to send visitors to those pages/articles) could
create broken links.
I would by all means rather use relative URL paths for stuff like imgs, js etc for ease
of implementation but since my knowledge of php is near non-existent at this current
time, I’m not sure how I would go about achieving this easily without some serious
self education first. If you know of a resource or can point me towards one, I’d be
grateful. Many thanks.
Awesome, thanks for the info. This is good to know. My current webhost runs Apache
so SERVER_NAME seems to be working as expected on the tests I’ve run. It’s good
to know that if I need to change to a host that runs NGiNX in future, this is something
I’ll need to look out for.
Markdidj ma man today you have saved me a lot of work!
So apparently this is a “root-relative” path. I fired up a couple of test pages
in obscure subdirectories on my remote server and it worked like a charm.
Gotta love it when things just work!
I had a couple of issues on localhost though. I’ve got my sites set up in sub-
directories with each being defined as a virtual host. The root-relative path
was resolving to localhost instead of the site’s root.
For example instead of the URL resolving to something like:
Needless to say the images, css, js etc had broken file paths. I got around this
by pointing mysite.local.com to 127.0.0.1 in my /etc/hosts file and
the rest as they say was history.
