Your Site Easily Transferable
At last you've found the perfect host for your website.
Your pages will be served more quickly, and more
reliably than at present. The available bandwidth
is going to be far more generous, and you'll deliver
secure pages, media streaming, and password protection
as standard. There's one big problem however, your
site has used a host-dependant search facility,
and your scripts (of which you use many) will all
require reconfiguration. That means some major redevelopment
is in the pipeline.
Join Rosemarie Wise as she investigates the issues
relating to the transfer of websites from one host
These days, there are more people offering hosting
than you can shake a stick at; while this may be
good for those of us looking for a cheap hosting
deal, it means there is also a high degree of uncertainty
associated with hosting. It shouldn't take too long
to find horror stories of web hosts offering shoddy
service or just disappearing without a trace if
you know where to look.
As a result, hosting is not so cut and dry as it
once was and you should design your site to be easily
transferable from server to server if you want to
reduce any hosting problems that you encounter.
The last thing you'll feel like doing if your host
goes bust is to edit all the links and server paths
before you can upload it to a new server.
Keeping your Links
One of the easiest ways to minimize server problems
is to use relative paths and URLs whenever possible.
This will remove any ties to your domain name, server
IP address and directory paths and make your site
more likely to work first time when you upload it
to a new server.
While it may seem like a good idea to have your
domain name in all the links that are going back
to your site, there are particular occasions when
this can be undesirable. What if you loose the domain
name, or need to use a temporary server while the
other is fixed? If you include your domain name
in each of your links, there is no quick and easy
solution to these problems that doesn't involve
editing DNS entries or editing the links. Having
your domain name fixed in your links also adds to
your page download time, so is probably more trouble
than it is worth.
If you have your own domain name or you control
the files in the root of the domain (as opposed
to limiting your files to a sub directory), then
converting links on your site to relative links
is easy; simply remove the reference to your domain
from the URLs. For example:-
The first slash in the URL is important as it tells
the browser that it should look for the file at
that path starting from the directory that the domain
For those that host their site in a sub directory
(as is usually the case for most free hosts), things
could get a little trickier. Using the style of
relative links above may work on your server, but
I wouldn't recommend it as you are unlikely to get
the exact same server set up on the next server
and would need to edit your links again anyway.
You could use the base tag to specify the base URL
of your pages and thus the behaviour of links on
those pages. However, adding such tags to your pages
does not help server transferability when your change
of host requires a change of URL; you would still
need to make changes to your site if you wanted
the transfer to run smoothly.
If you are hosting your site in a sub directory
of another domain then it might be a better idea
to use links relative to each file as opposed to
relative to the domain they are hosted on. Such
relative URLs will use conventions such as "../"
for the parent directory and can seem a little confusing
at first, but will come as second nature when you
make frequent use of them.
One of the biggest problems you are likely to encounter
when changing the server is that your scripts and
other interactive site elements will break. There
may be the odd occasion where you are lucky enough
to be able to transfer the site to a new server
and it work first time, but most scripts will require
to be reconfigured at some point.
Don't forget, particularly if you use a *nix server,
to change the permissions of the files that you
transfer... this is often overlooked when in a hurry
to get things up and running. Also make a point
to remember to upload your Perl scripts in ASCII
mode; otherwise you'll end up breaking your Perl
scripts without realizing it.
Use your Environment Variables
One way to reduce the amount of changes you'll need
to make to get your scripts running on a new server
is to make use of the environment variables whenever
possible. A well written script will use these to
learn where it is and what server it is running
on, making changes to the way that it works accordingly.
For example an ASP page could look for common email
components, choosing to use the first one it comes
across; the fact that your old server uses ASPEmail
and the new one uses JMail by default shouldn't
have to matter.
The PATH_INFO, SCRIPT_NAME and SERVER_NAME server
variables are a quick way for a script to learn
more about itself. If you are able to modify or
write scripts that can make use of these and set
other variables based on the environment they are
running in, you can go some way to reducing your
downtime when moving your scripts to a new server.
Of course there are likely to be some scripts that
are unable to make use of these or require that
you provide a hard coded variable based on some
server path that it is unable to detect. You can
speed up the time needed to change all these hard
coded elements in the future by grouping and declaring
all your variables at an easily recognizable location
in the script (for example near the top).
When the unthinkable
We'd all like to think that we'll never need to
change hosts and that taking the precautions to
make our sites more transferable between hosts is
a waste of our time. The truth is it could happen
at any moment; preparing for that moment should
be in the back of your mind when you are creating
new features and content for your site.
The more you can make your site and scripts less
reliant on hard coded server specific information,
the easier it will be to move them to another server
if, and when, the time comes.
author, Rosemarie Wise, is a self proclaimed
'web enthusiast' who set up her site, Web
Site Owner to share her experiences of being
a site owner.
has produced a great resource for anyone who'd
like to learn about, or develop their skills
in web design...
Although our contents are free to browse, copyright
resides with the originators of all works accessed
at AbleStable®, and unauthorised copying
or publication of our site contents is strictly
AbleStable © 2002-2007