Multisite Installations - Dev/stage workflow and folder naming

Events happening in the community are now at Drupal community events on www.drupal.org.
snorkers's picture

One thing I can't get my head around is how to set up the folder structure on my local development environment, then on a live host (eg sandbox stuff, site testing, demos etc).

Let's imagine on my local machine, with all the right virtual hosts set up as http://site1, http://site2, http://site3 etc, my drupal/sites folder would contain: drupal/sites/all, drupal/sites/default, drupal/sites/site1, drupal/sites/site2, drupal/sites/site3...

This is great and works locally. However, I can't have the same URLs on a public server and would have to use site1.mydomain.com, site2.mydomain.com, site3.mydomain.com (or similar)... Now, do I have to change my folder names under my drupal folder on the public server to drupal/sites/site1.mydomain.com (etc) or is there some rewriting cheekiness to be had in .htaccess? I can just see things getting way out of hand with FTP as my local development machine and my public site will have to have different folder structures/names.

The only alternative I can see is to use identical URLs on my local test environment as are on the public server, then turn off my local server, every time I want to look at the 'publicly-hosted' sites :(

Comments

Symbolic links / different IP in hosts

markus_petrux's picture

You can have the same directory structure as your production server for your development platform. Two methods that come to mind:

1) Using symbolic links.

sites/all
sites/default
sites/www.example.com
sites/dev.example.com (this is a symbolic link that points to sites/www.example.com)

Here you should make sure all settings dependent on domain name take into account both domains. Probably you don't need anything special, it depends on modules installed or additional infrastructure details.

2) Changing your hosts file temporarily to point your domains to different servers. Here the directory layout would be the same for both environments:

sites/all
sites/default
sites/www.example.com

Now, when you need to access your local server, just add the following to your hosts file:

127.0.0.1 www.example.com

When you need to access your production server, you can just comment that line and force the browser to perform a dns look up. Closing all windows often does the trick.

Sym Links

snorkers's picture

I hadn't even thought of Symbolic Links - what a simple solution! Solution #2 was the only one I could think of and seemed a bit clunky to keep tweaking the hosts file.

Thanks Markus

Like markus, I do this with

Garrett Albright's picture

Like markus, I do this with some hosts file trickery, but I avoid confusion which could occur from using the same domain name by instead using a fake one.

For example, if I'm working on example.com, I'll create a symlink inside the sites directory named example.test. Then I'll add example.test to my hosts file pointing toward my local server, instead of example.com, and head to http://example.test in my web browser for testing - that way I know that if I'm looking at a site at a domain with a .test suffix, I must be looking at the local version, whereas sites with a "real" suffix must be the live version. Since I generally synchronize with the remote site on a per-site-directory basis, I don't have to worry about accidentally uploading the symlink to the remote server, but even if I do it's no problem since it won't generally be accessible to anyone who hasn't tweaked their hosts file anyway.

This approach also works well for Domain Access-powered multisite installations - just install the Domain Alias module. When you're creating sites, give each site what will be its correct domain when the site goes live, but then also use Domain Alias to point a .test domain at it. Then edit the hosts file as normal. Easy peasy.

I've noticed a caveat with this approach, however - images processed by ImageCache get screwed up after you synch the database. I can't recall the exact details, but basically if you have an ImageCache-powered image working fine on your testing server running through one of these .test domains, the images will be broken on the live site - a goofy, incorrect path is returned for the image locations, and the browser never finds them. I've never taken the time to investigate why; instead, I just try to get to the point where uploading ImageCache images on the testing server is no longer necessary as soon as possible, then move on to other things.

If you're unfamiliar with tweaking your hosts file, you ought to find Wikipedia's article helpful.

This patch is probably your

redndahead's picture

This patch is probably your best bet in helping you with your staging issues. http://drupal.org/node/231298

It will allow you to create an associative array that points your url to your specific folder. This will save you from having to change the files and variables tables when you move from prod to dev. Your sites folder could have a directory of something like example.com and you can make example.test and example.com both point to that directory.

Never would have found that!

snorkers's picture

Thanks @redndahaed - would never have found that patch if you hadn't flagged it up. Took a long time to read through the whole thread, but all useful stuff. Shame it isn't being committed to D6.

Multisite

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: