2

I want to host a Drupal 7 site that effectively has four different silos of information. The architecture will look like this:

  • example.com - Blog site with content about the parent company
  • example.com/foo - Informational site about sub-company "foo"
  • example.com/bar - Informational site about sub-company "bar"
  • example.com/fubar - Informational site about sub-company "fubar"

The top site will pretty much be a blog with navigational elements directing people to the sub-sites. The three sub-sites will essentially be the same structure, but have slightly different CSS (different color schemes) and have different information. Logins can be separate, because we actually want to be able to peel away one of the subsites to sell as an asset, if need be.

I'm wondering what the best way to do this would be. Multi-site should keep it easy to update, because the modules and core should be upgraded in lockstep. However, I can't seem to get multi-site to work for these subpaths.

Is multi-site the best way to go here? Or should I just host four different instances of Drupal, one for each site?

(Note, I saw a question about subsites just after I posted this, but it seems that subsites is only available for Drupal 6. Please correct me if that is wrong!)

Improve this question
1
  • nmc's answer helped me get going with subsites (you don't need the subsite module). If anyone has any input as to whether this is the best way to do things, I'm still looking for that.
    – Michael Herold
    Aug 26, 2011 at 23:03

4 Answers 4

Reset to default
2

Subsites should work for Drupal 7 as well (assuming this is what you're working with). I've found these instructions helpful in the past: http://drupal.org/documentation/install/multi-site

If the company subsites you are running are under one parent company where there is one body of management (a common decision maker), then subsites makes sense. If they are different companies which may want very different functionalities for their sites, then it may not be wise to combine them into subsites which rely on the same code.

Improve this answer
1
  • There seems to be a lot of mix-up with nomenclature. What I saw that was only available for Drupal 6 is the subsites module. I'm giving the multi-site information you linked another try; I somehow never stumbled upon that particular page!
    – Michael Herold
    Aug 26, 2011 at 22:41
0

The Domain Access module may fit your bill, but it is more geared towards subdomains and not subdirectories. It is worth looking into, though, if you want to have a common database.

If I were you, I would try to use subdomains instead of subdirectories regardless of the approach you take. In the long run it will probably make life easier for you when you want to split a site off.

Improve this answer
1
  • That sounds like a nice module that makes subdomains easier without fiddling with Apache. Unfortunately, I don't have that option; the client is adamant on having the sites be subdirectories.
    – Michael Herold
    Aug 27, 2011 at 19:08
0

Did you ever get the answer to your questions about which to use? I'm looking at it the other way. I have multiple sites, all in the same hosting account, and in separate folders. Each has it's own domain name and it's own install of Drupal. I'm considering whether I should consolidate them to a multi-site installation.

What did you wind up doing? I did find a good article that discusses how to take a multi-site to a standalone site (which you would need of you used multi-site and then sold one of the sites): http://technopoetic.com/2012/04/convert-a-drupal-multi-site-installation-to-a-single-site/

As far and when to use which? I still don't know. I hate having to install and update the same modules over and over. I've never done a multi-site install before and I'm sure that I'm torturing the web server with all of the instances of Drupal (however, they are just php files).

If you have a single admin for all, I suppose multisite is the way to go. With multiple instances of Drupal, I can easily move any of then indepenantly.

Let me know what you decided and how it went.

Improve this answer
3
  • It's been a while since I dealt with the client, so I don't recall all the reasoning. I went with multisite so I only have to have one copy of the Drupal code to update. However, I still have to manually update modules for each individual site, so it only saves me a small amount of effort. I think if you're doing sub-sites (/sitename vs. sitename.domain) this method works the best, as it was the least troublesome to set up. Hope that helps!
    – Michael Herold
    Aug 1, 2012 at 14:39
  • I thought that the whole point of having an "all" folder under sites (in addition to "default" for a single site and site-specific folders for multi-site) was that common modules would be in the "all" folder and would only need to be updated once? Is that not accurate?
    – John
    Aug 2, 2012 at 15:25
  • You're right. Ironically, I'm doing more work for this client currently. It looks like I misspoke in my original comment. I had to go with multiple installations due to the web hosting the client uses. So I have sub-folders each for each individual site. It's a bit kludgey, I admit, but it works!
    – Michael Herold
    Aug 8, 2012 at 2:33
0

If you go with multi-site and then break the site...every site is broken. At least if you have multiple installs of drupal and then screw one up, then only one is gone.

People like me have to consider the mistakes we make.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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