Whenever you move a web-site from one host to another it’s possible that something will go wrong. Common issues are incomplete transfers and incompatible settings – changes are required to make your site run on the new account. So before going public on the new server you want to view the site there and fix any issues that may arise.
But if the site isn’t publicly available (or if the public site is still on the old server) how do you view the site on the new server?
One option may be Userdir url format – you type the url into your browser something like this:
http://192.168.255.255/~account
(use the IP address and username provided by your new host)
However this will not work if the new host isn’t running the mod_userdir module, and it’s often not very useful for a prolonged test anyway – your pages will usually display links on each page in the conventional format that will direct you straight back to the old server.
I believe a better option is to take control of your own DNS. DNS is the service that translates your domain name to its IP address. So when you type yourdomain.example.com into your browser you want your private DNS to translate this to the IP address of the new server, while the public DNS service continues to send all traffic to the old server.
The easiest way to achieve this is by editing your hosts file. The hosts file is a simple list of “hard-wired” domain names and IP addresses that will bypass the normal DNS lookups. In linux systems the hosts file is usually found at /etc/hosts. In Windows systems it varies, but is commonly {windir}\system32\drivers\etc\hosts. This is a regular text file – open it in your favourite text editor and add a new line at the end:
192.168.255.255 yourdomain.example.com
ie. Your new account’s IP address and your domain name, separated by one or more spaces. Save and close the file, then restart your browser. Now browse to your web site and you’ll be seeing it on the new server. If the migration has gone well you may not notice any difference – if so you can check your server logs or use a phpinfo file to verify that you’re seeing the right server.
To use the phpinfo method, create a new text file called, say myphpinfo.php (you can use any name you like, but preferably don’t use “phpinfo.php” – it’s better not to show this information publicly and that name is just too easy to guess!). Inside the file, place just this line:
Upload the file to your new hosting account using FTP and then point your browser to yourdomain.example.com/myphpinfo.php – you should see extensive information about the server and the version of PHP running on it. In the top line with the heading “System” you’ll see details of the server operating system (typically Linux) and the hostname – a sure indicator of which server you’re connecting to.
Important! When you’ve finished checking the site, reverse your change to the hosts file, or just comment out the line you added by placing a hash character (#) at the beginning of the line. It’s easy to forget this and once you’ve transferred to the new server you might not even notice it’s still in place… until the time comes to move again and you can’t understand why everyone else is seeing a different web site to you! Don’t say I didn’t warn you…
Restart your browser and you should be viewing your site on the old server again, along with everyone else.
July 24th, 2011 at 8:57 am
I’m trying to redirect the site locally using the windows hosts file but not sure about the format – the traditional format works file:
123.123.123.123 www.example.com
but in this case we’d like it to redirect to 123.123.123.123/~sitename
When I enter the below though it doesn’t work:
123.123.123.123/~sitename www.example.com
Any suggestions as to how I might fix this using the HOSTS file – I’d rather not play around with the phpadmin and databases if possible?
July 24th, 2011 at 3:41 pm
You can’t. DNS (and the hosts file) is only for translating a host name to an IP address. So www.example.com gets translated to 123.123.123.123. But the mod_userdir format (123.123.123.123/~sitename) is itself just another workaround to do the same job – viewing a website before the DNS has propagated – you don’t ever need to use both.
So if you have a website that’s available as http://123.123.123.123/~sitename it should also be available as http://sitename.com, with sitename.com being whatever domain you set up at your host, provided that DNS (or the hosts file) connects 123.123.123.123 to sitename.com. I don’t see why this would require you to change anything in the databases unless you’re deliberately setting up the website on 123.123.123.123/~sitename, which would be a very bad idea – requiring you to change these details anyway before the site goes live.