On websites with traffic outside of a group of coworkers, you may find it desirable to modify a copy of the website, and then periodically upload the new version. Both the main robotics website and TMS (”Team Management System”) are developed apart from the main website, and then the drafts are periodically “pushed” onto the main site.

While this technique may not seem particularly impressive to some, some problems come up when you actually try to implement it. The most major problem is that when you push, all the links are now broken. A link to /draft/page.html needs to become /page.html when the page is pushed, and this is hard to automate. (A simple regexp is not enough: what about favicons and stylesheets?) The more minor problem that comes up is design-based, and depends on how you plan to store your pages. If you use a simple filesystem-oriented storage method, there will be no problem.

There are three approaches to handling the link problem. The first is to manually change the URLs in the links, maybe writing a few scripts to help. This quickly degenerates into chaos; however, it is the only one that works well with a simple, filesystem-oriented website. If you have a serving script, you can make all your links be to urls of the form $prefix/page.html. Then, in your serving script, you can have,

  1. if(ereg("^/draft",$_SERVER["REQUEST_URI"])) $prefix="/draft";
  2. else $prefix="";

This is the method TMS uses. The flaw is that you have to be careful to begin every link with $prefix.

The third method might be a bit tacky, but is much more effective and reliable. Like #2, it requires a serving script. Insert the following at the top of your serving script:

  1. if(!ereg("^/draft",$_SERVER["REQUEST_URI"]) && ereg("edu/draft",$_SERVER["HTTP_REFERER"])) {
  2.     header("Location: /draft".$_SERVER["REQUEST_URI"]);
  3.     exit;
  4. }

Any link on a draft page will appear to link to the main page; however, when the link is clicked, the browser will receive an HTTP 302 redirect to the drafts page.

If you are using a serving script with meta-information stored into a database, you may come into another problem: should you store two completely separate copies of the database, or should you only separate the content and have a single database. TMS only separates the content – as a result, when a page exists in the draft pages but not in the main pages, the user will get a “page not available” message if he tries to access that page. In addition, deleting pages can be annoying, since you can’t actually remove the page from the database until the drafts have been pushed. In contrast, the main site takes the middle road. The pages and their meta-information are all kept separate from the drafts and their meta-information, but all other data, like quotes and articles, is the same regardless of whether the draft copy is being viewed or not. Depending on your needs, you might want to pick another option.

Related posts: