While on the phone recently with a Web host, I mentioned wanting to create a second domain to be used as a dev space, and was surprised that this was the first time they had heard the idea.
Here’s the deal: once your site is launched to the public, you can’t make changes to it without the public seeing your work-in-progress. For normal updates, like staff name changes or today’s news, you’re probably fine to make the changes, save and upload (or however you publish), and it’s live.
But for major redesigns or site additions, you’ll need a copy of your production site that you can privately work with, test, make more changes, integrate the necessary link changes in other related pages, and demo to stakeholders — all before launching.
Some people create a “newsite” folder on the existing site and start work there. Problem is with the links and scripts. Since your new site is one folder deeper than the root, all the (relatively pathed) links are one level deeper than they’ll eventually be, and scripts are also in the wrong location. Most WYSIWIG Web tools promise to manage these links for you, but be careful: my experience has been that links get broken or not updated in the process, and moments before launch is not the time to be worrying about whether everything still worked.
Fortunately, there’s a better way. Work with your Web host to set up a special domain, such as dev.yourdomain.com (technically, a “subdomain,” but Microsoft and others use similar terms differently, so people sometimes get confused). Now your new home page will be exactly in dev where it needs to be once it moves to production, all your scripts can be in the cgi-bin or other safe location and you can be assured when you publish that it’ll stay that way. You can copy the entire old site to dev and integrate new content or applications into it, adding crosslinks to and from existing content, so that testers can click anywhere and see how the pieces fit together.
