Version Control for Web Sites Options

[RowanB]

What's the best way of achieving version control for a published web site?

Like thousands of others, I look after several small web sites for myself and my family and for various organisations that I belong to. I develop the web pages either directly in HTML and CSS, or using my favourite web authoring tool of the moment (usually freeware or open source tools). I also often use PHP, Python, ASP and other scripting languages. Some of my sites use MySQL or MS SQL databases. When I've developed some new content I then up-load the changed files to the shared web server of my hosting provider using FTP. BeyondCompare (a great program) is my favourite way of doing this. I don't have a fully configured web server at home, so uploading to my web hosting company's server is the only way I have of testing my content.

What I need now is a way of updating the web site in such a way that certain people to whom I've given a password (often officers of the voluntary organistation whose web site I'm working on) can view the new content, but that other users (including the general public) continue to see the old site. Only when I've got approval from everyone who needs to give it do I want to make the changes live, so everyone can see them.

I would prefer not to have to have two complete copies of the site on the web server, one password protected and one not. This is because:

1. It would take twice as much space on the web server
2. I would have the hassle of copying the whole of the site from the protected location to the public one
3. The site would need careful design to avoid the need for changes to the content for the two locations
4. If I have databases, PHP scripts etc. in the site it becomes even more difficult to make both sites work exactly the same as each other.

So I would like to have only to upload new or changed files (or even better, just the diffs between the old file and the new one).

What's the best way of doing this?

Of course there are many other things that an ideal system should do:

• keep a record of the complete change log
• optionally, display the current version number of each page, and the date it was released
• allow me to revert to an earlier version
• allow approvers to submit corrections or comments on new content
• optionally, highlight new content to users, and even show the changes
• etc.

Many of these are things that any good source control package like Subversion does, but maintaining public (released) and unapproved content on a remote web server seems to add some more complication.

I hope someone can suggest a good way of doing this, preferably with free or cheap software...

Thanks - Rowan

[wgabrie]

I have two thoughts on this:

1. You could run a test site in a hidden, obscurely named folder that is completely disconnected from your main site. The test site would just contain empty "lorem ipsum" pages and testing items you want to try.

2. You could create and keep an archive for each version of a page as a distinct file (or database entry) which would still be attached to the main site but, to keeping prying eyes out, its a hidden, custom named, unlinked page.

You being the creator of the pages would know the real test page's URL to use for access and testing purposes. So you don't have to build up a new site only to change a paragraph or add an object that only affects one page, but you want to be extra careful while testing the new page not to break any of your site's main databases.

Finally, when you are done testing the page you can use the redirect ability of a server-side script or .htaccess file's 301/302 redirect, if you have an apache web server, to move your site's static URL between different versions of the page.

This post has been edited by wgabrie: Sep 6 2010, 07:18 PM

[wgabrie]

Here is a page on how to do 301 redirects in several programing languages: 301 Redirect - How to create Redirects

[Darin McGrew]

I would prefer not to have to have two complete copies of the site on the web server, one password protected and one not. This is because:

1. It would take twice as much space on the web server
2. I would have the hassle of copying the whole of the site from the protected location to the public one
3. The site would need careful design to avoid the need for changes to the content for the two locations
4. If I have databases, PHP scripts etc. in the site it becomes even more difficult to make both sites work exactly the same as each other.

So I would like to have only to upload new or changed files (or even better, just the diffs between the old file and the new one).

I would recommend having a complete staging environment because:

1. Disk space is cheap.
2. It would be more of a hassle to create a staging environment that uses an updated subset of your site, but that somehow injects the current version of documents that haven't been updated.
3. It isn't that hard to use relative paths. Or if you set up the staging environment on a new server name (e.g., beta.example.com rather than www.example.com), then you can use root relative paths. Or if you want to use full paths, then you could configure your staging test systems to use a custom DNS server that provides the address of your staging server rather than the address of your live server.
4. I would think that if you have databases, that it becomes even more important to separate your staging environment from your live environment.

What's the best way of doing this?

I think the best way is to create a separate staging environment. But you seem to have rejected that idea.