The small website I built a long time ago is starting to pick up a little and I'm starting to run into problems with making changes. Originally, all the pages were .html and I would edit and test them offline to make sure everything worked. Then I realized how helpful php includes were, so I changed everything to .php and used includes. Without apache, I could no longer test offline, so with Filezilla, I would choose the "view/edit" option on files that were already on the server, edit them, and then have them uploaded again. This is what I've been doing so far and it's worked pretty well for the most part. I just save the temp file that filezilla creates, and let it upload it back to the server.

Yesterday, I realized that one of the javascript files I had worked on the day before had been replaced by an empty file. This was something to do with sublime text keeping the non-existent temp file open/filezilla uploading an empty file - I'm not really sure what happened, but it shouldn't have been able to happen. And now, I need to change the design of the site, and doing that one page at a time would be noticeable, so I need to do it offline first.

I would like to use version control and install apache so that I can completely test my site offline, but there are a couple problems I have with this. The first is that I have a Forum on the site. I could install mysql and export the tables, then import them offline, but then, while people are making posts on the website, the offline copy becomes out of date and I can no longer upload that back to the server. I also have some Python scripts on the site using WSGI. My webhost's settings are very specific, so if I wrote python scripts offline and ensured they were working, I wouldn't know if they were going to work online.

Should I edit everything offline and upload it all back to the server when it works? What happens if a php or python script executes one way on my local machine than on the server?

  • 4
    Why would you have to reupload your out-of-date tables?
    – Maxpm
    Commented May 9, 2012 at 20:52

5 Answers 5


Version control will only help to the extent that you will be able to go back to previous (hopefully working) versions.

It will not help with botched deployments and changes.

You need to have a test environment - a web server that you can put the changes on and test them and only when happy, push to a live (publicly visible) web server.

  • What I was saying was that I could make my local machine my test environment if I installed the necessary tools, but I wouldn't know if things that worked locally would work live.
    – mowwwalker
    Commented May 9, 2012 at 19:32
  • 3
    @user828584: That's why you have to make sure the configuration on the test environment is as close to the production environment as possible. Things that will probably differ a little no matter what you do are usually configurations related to the server itself, such as references to the server by IP address or domain name, or paths to libraries or directories that are different because of different OS's or filesystem structures. These are things you can't always avoid but should still try to account for. Commented May 9, 2012 at 19:34
  • @FrustratedWithFormsDesigner, How are things normally done? With a second server like Oded mentioned?
    – mowwwalker
    Commented May 9, 2012 at 19:52
  • @user828584: Yes, the testing is usuaslly done on a server that's running locally, such as on your desktop, or on a secondary machine in your office. This server should not be accessible from the outside world, just from your testing machine. Commented May 9, 2012 at 19:58
  • @FrustratedWithFormsDesigner - Normally, development is done locally, then basic testing, UAT, staging and finally deployment to a live environment are each done on a different, dedicated server (at least in any large enough organization).
    – Oded
    Commented May 9, 2012 at 19:59

I'm going to assume that you're using Windows, but this also works for Linux and Mac.

First, I recommend you install XAMPP on the computer you work on. It is a bundle of Apache, MySQL and PHP, install it and give you a basic configuration that should be good enough to test the basics. Your entire site then can reside on your PC and you save a lot of time on the uploading/testing. All you have to do is save the file and refresh the browser.

Second, I recommend you have a development version of your site on the same server that hosts the site. It looks like your site is not huge, so this shouldn't be a problem. What I do is have a www.mysite.com/dev directory which holds the entire site. After I make any change, I upload the changed files to the "dev" folder and test them. If all is well, I know that I can upload to the root folder and it will probably work as well. I protect the /dev directory with a .htaccess file.

So, in summary:

  1. Make changes on your local copy of the site.
  2. Test changes locally (on http://localhost/yoursite)
  3. Upload and test changes on yoursite.com/dev
  4. Upload and confirm on yoursite.com.
  • This sounds like a good idea, and I think this is what I will do. Though, the server also has WSGI/passenger-WSGI for Python. Do you know anything about installing those and getting them to work?
    – mowwwalker
    Commented May 9, 2012 at 21:15
  • If all my links are to "/images/image.png", how do I make them go to "/dev/images/image.png"? Is there something I can put in the .htaccess file to do this?
    – mowwwalker
    Commented May 10, 2012 at 0:22
  • Are you using Windows? stackoverflow.com/questions/999532/passenger-on-windows Commented May 10, 2012 at 0:33
  • DO you mean that you used relative paths like ../images/image.png? My problem with that is that some of the scripts and css are included via PHP, where the path needs to be absolute.
    – mowwwalker
    Commented May 10, 2012 at 0:48
  • let us continue this discussion in chat Commented May 10, 2012 at 1:12

You need a test server.

If your own PC runs Linux or some Unix flavor already, installing Apache should be easy. If it doesn't, build your own server - simply pick a decent Linux distro (I recommend debian, it's super-reliable and easy enough to install, but there's plenty others to choose from), and install it either on a spare PC you may have lying around, or inside a virtual machine on your own PC.

The added benefit of a dedicated test server is that you can test not only your code, but also your deployment procedure, especially if the test server is very similar to the actual environment (same directory structure, same software versions, etc.).

You'll also pick up the basics of *nix system adminstration, which is good because you'll understand better what you are doing as a programmer.


I sense that you're not all that open to setting up a test server. I don't blame you. How about creating another hosting account and testing your site there? Deploy it from SCM when you're testing. When you're happy with it, deploy it to the 'real' domain.


In 2012 the best model is something like heroku or app harbor use -- you commit to a specified repository and your stuff gets pushed up. Rollbacks and version history are easy because you are using a solid source control system to handle it all.

In the case of a static website, you can simulate this pretty easily using a script that just does the appropriate command line call to update a folder at your specified intervals.

Not the answer you're looking for? Browse other questions tagged or ask your own question.