 |
 |
Login / Sign Up |
|
Home >> Articles >> Web Site Design >> Relatively Speaking, keeping your Site easily transferable.
Author: Rosemarie Wise
Added: December 31, 1969
Views: 1,944
Rating: 4/10
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 Relative
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:-
http://domain.com/directory/filename.asp
becomes /directory/filename.asp
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 points to.
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.
Transferable Scripts
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 happens...
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.
More Web Site Design Articles
|
|
|
