Advanced Drupal Webshop

If you're part of a webshop that builds or maintains large numbers of dynamic client sites, you've probably considered adopting Drupal into your bucket of tricks. And if you've been around Drupal for a while, you have certainly considered Drupal Multisite. Its certainly chaotic maintaining and updating Drupal modules across different domains. There might be ways to reduce the confusion and get things under somewhat of control.

Use advanced Unix account configurations and conventions.
It is a good idea to keep your home folder of your principal user clean. There is a wiki entry that will help get an understanding of some unofficial but generally accepted (advanced) Unix account setup. Use that page as a reference and run the setup scripts each time you create a new user account.

Use multi-site Drupal religiously.
There are lots of ways to set up your client sites. The following explanations will allow all your sites to run off the same Drupal code, and even allow the ability to isolate drupal folders for specific clients. However, with Drupal multi-site there are two ways to configure multi-site:


 * Direct apache configuration : Make your domains point directly to the www/drupal folder from the Manage Domains > Edit page in the control panel. This puts the change directly into the apache configuration files, you don't see an entry in your file system for the domain and have to just "know" that it points to Drupal.
 * Symlink configuration : Make each domain have its own folder, but replace the folder with a symbolic link to Drupal. This method requires a few extra steps but has the added benefit of being able to see in the file system whats going on with your domains.

We are going to explain the second solution and describe how to setup Multisite Drupal with multiple users. This document assumes you're familiar with Drupal Multisite Install as well as with pertinent information provided at [drupal.org], [example].

At the end of this tutorial you will have a file system that looks like this:

/home/user1/www/drupal <--- where Drupal is installed /home/user1/www/domain1.com -> ./drupal (symlink) /home/user2/www/domain2.com -> ./drupal (symlink) /home/user1/www/drupal/sites/domain1.com <--- where domain1.com's config/files/modules live /home/user2/www/drupal/sites/domain2.com -> /home/user2/data/domain2.com (symlink)

This tutorial takes advantage of the non-standard www/ subfolder location for placing all of your domains into a more organized subfolder, and out of the home folder. Its a customization recommended as part of the Unix account setup mentioned above. Basically, when creating new domains in the panel, make sure you specifically change the default location (ex. 'domain.com') to include the 'www/' subfolder (ex. 'www/domain.com')

''Note: You could also install drupal into soft/ or perhaps even somewhere in your bin/ folder. I have it in www/ so the domain name symlinks are shorter when printing an ls -al''

Use secondary user accounts.
The Unix account setup page describes the use of multiple user accounts. Here's how a setup might look combined with Multisite Drupal in your main user's www/drupal folder.

When you create a secondary user account it comes by default with the same Unix group. You just need to make sure the main user's Drupal folder is group readable and executable.

chmod 750 /home/user1/www/drupal
 * 1) as user1

Now login as user2 and configure the new user's environment, and link to user1's Multisite Drupal install folder:

su - user2
 * 1) as user1

cd ~ cd www ln -sv $RUN/www/drupal
 * 1) as user2
 * 1) run scripts on Unix account setup page, ensuring the www folder gets created
 * 2) see http://tinyurl.com/c9byb6
 * 3) then link to drupal...

Then create the new domains configuration in the panel for the user2 instead of user1 and specify the www/domain.com for the folder location. Finally, remove the created folder and replace it with a symlink to drupal.

cd www ln -svf drupal domain1.com
 * 1) as user2

The final setup will look like this:

/home/user2/www/drupal -> /home/user1/www/drupal  (symlink) /home/user2/www/domain1.com -> ./drupal  (symlink)

Now continue with standard multi-site drupal instructions. Copy the sites/default/ folder to sites/domain1.com and then quickly install the rest of drupal instance from the web.

cd www/drupal/sites
 * 1) as user2

cp -R default domain2.com chown -R domain2.com user2   # make user2 the owner of the folder chmod domain2.com 740        # make sure other users cant edit files

mv domain2.com/default.settings.php domain2.com/settings.php chmod 740 settings.php

Its possible you might have problems dealing with symlinks from some FTP clients not being able to actually navigate into the Drupal instance to get to their sites/domain.com/files folder to access uploaded files etc. In that case I make the folder locally and then symlink to it inside the drupal/sites/ folder:

/home/user2/data/domain2.com <--- copy the contents of ~/www/drupal/sites/default here /home/user2/www/drupal/sites/domain2.com -> ~/data/domain2.com (symlink)

Tell your clients to upload their web files via ftp to data/domain2.com/files/upload

Working with accounts on other servers.
Sometimes you're faced with complex situations such as clients who need other webhosts, or even clients with DH account but on a different server.

In these cases its fairly impossible to do the multi-site setup explained here. Its about 99% probable that if your client has their own DH account, it sits on another server than your own. Thus the symlinking tricks explained above won't work.

It could be possible to get DH to move the user to your server where you can then setup appropriate Unix groups to allow a symlink between their url folder and your Drupal multi-site install in your principal user's account. This has not been tested nor confirmed.

The only suggestion at that point is to try to maintain these offsite sites up-to-date by rolling your own synchronization mechanism. You could try your luck with rsync or implement a subversion repository of modules and perhaps even core Drupal code as well.

Use subversion to keep a local repository of your standard modules.
You may want to maintain your own subversion repository of latest stable contributed modules that you wish to provide to all your sites. These are typically installed in the sites/all/modules folder. I keep the multi-site Drupal's sites/all/modules</tt> folder in sync with potentially other Drupal installations on other webhosts or on other DH servers that arent connected directly to my main account.

Updating modules

I update to latest modules by hand using curl and untar, then do a svn commit. Then go to all the other drupal installations on other servers and pull the updates and run the update.php script from their respective urls.

Its also possible to [update modules with CVS].

Using CVS

You don't need to actually maintain an entire copy of Drupal core in another revision control system because you could maintain it directly with [Drupal CVS]. Syncing Drupal modules across different webhosts using homegrown subversion or Drupal CVS are outside the scope of this document.