tags:

views:

194

answers:

3

I'm using multisite to host my client sites.

During development stage, I use subdomain to host the staging site, e.g. client1.mydomain.com.
And here's how it look under the SITES folder:

/sites/client1.mydomain.com

When the site is completed and ready to go live, I created another folder for the actual domain, e.g. client1.com. Hence:

/sites/client1.com

Next, I created symlinks under client1.com for FILES and SETTINGS.PHP that points to the subdomain
i.e.

/sites/client1.com/settings.php --> /sites/client1.mydomain.com/settings.php

/sites/client1.com/files --> /sites/client1.mydomain.com/files

Finally, to prevent Google from indexing both the subdomain and actual domain, I created the rule in .htaccess to rewrite client1.mydomain.com to client1.com, therefore, should anyone try to access the subdomain, he will be redirected to the actual domain.

This above arrangement works perfectly fine. But I somehow feel there is a better way to achieve the above in much simplified manner. Please feel free to share your views and all advice is much appreciated.

A: 

Since it seems you want to reuse the files/ directory and settings.php from your development domain, I'd suggest using the default/ directory + symlinks to achieve your goals.

ie, during development

sites/default/settings.php
sites/default/files/
sites/client1.domain.com -> sites/default (symbolic link)

once you're ready to switch over to their domain:

sites/client1.com -> sites/default

You can then remove client1.domain.com from your virtual host (or continue with your rewrite, etc...).

It will accomplish the same as your method, but you get the added "protection" of all requests going to default in case you add an additional domain at a later date as an alias (for example).

Owen
Ah... I see what you mean there. It looks like a good solution for staging a single-site environment. But for multisite I guess this wont work. Thanks for your answer however, appreciate it.
deanloh
A: 

If you're simply sharing core and module files between the sites, you can use a different symlink layout.

In my setup I have all of the shared files in a common, non-web-accessible directory:

/var/www/drupal
/var/www/drupal/sites/all/modules

then for each deployment, common files and folders are symlinked to those files.

/var/www/client1/public_html/index.php -> /var/www/drupal/index.php
/var/www/client1/public_html/includes  -> /var/www/drupal/includes
...
/var/www/client1/public_html/sites/all -> /var/www/drupal/sites/all

Then you can place the site's settings.php and any modules or themes for only that site in the default sites directory

/var/www/client1/public_html/sites/default 

This layout also offers you the flexibility to override any common files as necessary, such as .htaccess.

To move from staging to production, you will just have to modify your virtual-host configuration from the staging to production domain name.

GApple
A: 

If you don't like a ton of symlinks, another option is using the Aliased Multi-Site Support patch: http://drupal.org/node/231298#comment-1420180

This will allow you to specify in configuration that any requests for client1.domain.com should actually use /sites/client1.com/ instead of /sites/client1.domain.com/.

Then when you move to production, you can just remove the configuration setting (though it doesn't hurt anything if you don't).

This feature is part of Drupal 7, but as a new feature won't be added to Drupal 6. More good news is that you won't even need to use it in D7 just for file paths, since instead of storing the full path to files in the database, they use a schema such as public:// or private:// which Drupal then maps to the correct file system path, allowing multiple storage types/locations with much better portability.

GApple

related questions