What is the best and most efficient way to set up two versions of the same website?

I want one version that is online and open for everyone to use but I also want a developer version where I can develop and test new things instead of doing that against the ftp.

Currently I have MAMP setup on my developing machine and I use Git for version control.

In MAMP/XAMPP the location for the files are localhost/example/ and on the ftp it is the host's (Dreamhost's in this case) file structure. Something like /home/username/example.com/. That results in having multiple versions of pretty much the same file. This isn't that efficient but I can't come up with a good solution for it. Are there any?

It would be perfect if I wanted to add a new feature to the website I could do that in MAMP and when i commit the changes with Git it uploads the changes to the ftp.

  • symlinks to those files? i somehow don't exactly understand the ftp part... – thorsten müller Apr 12 '13 at 19:00

what I do with XAMP is that I have on my local an entry called a.com that points to my

so i reference pages as a.com/....

Keep the same files in both the places. have some custom include that checks if the current page has a.com and makes root links differently. Something like :

if( $_SERVER['SERVER_NAME'] == 'a.com'){
    $filePath = 'images/'
    $url = "http://a.com";
    $env = 'd';
    $imgPath = '/home/sites/example/images/'
    $path2 = "http://example.com";
    $env = 'p';

    //now this can be an include file in other files
    //in the other files just use the previously initialized variables when making paths and URLs. This keeps the code in the main files simple and the details in one file
  • What I meant with Since the ftp has some root folders and the local version has another set of folders the links to different pages and files are different. was that in MAMP/XAMPP the location for the files are localhost/example/ and on the ftp it is the host file structure. Something like /home/username/example.com/ – Oskar Persson Apr 12 '13 at 20:33
  • yes so why should that make a difference? you are making links on the web pages right? meains example.com/index.php has a link to example.com/subfolder2/page.php so the link looks like 'subfolder2/page.php' relative path. Where is it the full path? – tgkprog Apr 12 '13 at 21:35
  • I use full paths for my links cause the site urls are "dynamic". What I mean is that I have a frame on every page where some extra content is loaded in using ajax. The extra content contains links and therefore I must set the full path cause the page that loads the content have different urls (of course). I use /example/images/ on the local version and /images/ on the public one. It's worse when I have to use file_exists() cause then I have to be more precise. On the public version I have to write /home/username/example.com/images/. – Oskar Persson Apr 12 '13 at 21:43
  • 2
    Sounds like you just need to use a separate configuration file that contains variables customized for each environment. – zzzzBov Apr 12 '13 at 21:48
  • yes to what zzzBov that is what i was trying to say in my answer "OR have some custom include that checks if the current page has a.com and makes root links differently. " why i do that is so i do not have to care if i over write the file, they are the same on server and on local. they just check if the web page is 'a.com' (dev) or 'example.com'(real website) and then set up the root variables accordingly (if dev{ path= 'images';... } else {path = 'example/images'; ...} – tgkprog Apr 12 '13 at 23:14

Forget about FTP.

  • Setup a bare repository on the server
  • Add it as remote to your development environment.
  • Clone the bare repo to the webspace, adapt the configuration files.
  • Add a post-commit hook on the bare repo, starting a shell script on the webspace that pulls from the bare repo.

With that, you just push your changes to remote, and it is automagically drawn into the webspace.

Any environment specific constants do not belong to the code, but into configuration files, which are added to .gitignore.

  • I handle it similarly. The entire server setup is under version control. SVN commit from my dev system pushes new features to the repository, and then I can have any server instance pull the changes with an SVN Update. No automatic hooks, because there are multiple servers and they shouldn't necessarily be updated all at once, but using version control instead of FTP is definitely the right idea. – Mason Wheeler Apr 12 '13 at 23:37

Your Answer

