I'm currently in the process of developing a site that I though may be a candidate for a multisite configuration, but I'm not certain. Basically I will ultimately be creating a number of subsites based on geographic location (something in the realm of how craigslist does it). There will potentially be quite a few nodes. Since individuals will come to the site to view info specific to a location, I though for the sake of database size, it might make sense to split it up. I guise to cut to the chase, I'm wondering what the advantages are based on my critera. I also wonder about the following things.
shared users: if the users table is shared, can users stay logged in as they move from one multisite to another?
shared content: there is a tertiary cck type that I would like to share across both sites, does this complicate things?
references: is there a way to reference a node on another multisite (other than making astatic link)?
updates: will the standard method of updating the database still function with a multisite configuration?
Thanks in advance for any info
Comments
If all are the subsites are
If all are the subsites are going to be identical or nearly so, that's a strong indicator against using multiple sites and instead using Organic Groups or something similar. That's what g.d.o does. I would strongly recommend investigating that approach. If you want to be able to easily add and/or remove sites in the future or even allow non-technical users to do so, that's another indicator in favor of an Organic Groups-based approach.
I can't answer your first two questions (I don't really understand the "shared content" one… "cck type?"), but with regards to "references," no, there's no easy/sane way to do that; and with regards to "updates," it depends on what you mean by "standard method." You can put upgraded modules in the "sites/all/modules" directory to make them available to all sites, but you need to run the update.php script on all sites so that all necessary database updates run. Drush makes this much easier, however, by letting you easily run a command against all sites in a multi-site installation with one command:
drush @sites updb. One of many reasons why I strongly recommend learning how to use Drush if you run a multi-site installation (or any other installation, really, but for multi-site, especially so).The Boise Drupal Guy!
If you want to have a number
If you want to have a number of different subdomains, like seattle.example.com and phoenix.example.com, then you likely want to use Domain Access module to make them 'affiliated' in the eyes of the end user. This would be a non-multi-site setup, with Domain Access doing the heavy lifting per subdomain. http://drupal.org/project/domain
The main reason to run completely different sites as a multi-site setup would be to manage and update everything in one place with drush, as Garrett mentions.
Domain Access learning curve requires a lot of reading.
Just be warned. Read every bit of documentation you can find on this. It can be surprising.
The documentation that comes with the modules is substantial - read before you jump. The documentation is excellent, though, some of the best.
agree on domain access
This module does what it says. However, It took me a long time for it to sink in. After a lot of testing I found that traditional multisite or organic groups handled access to content and themeswitching and member features better.
Domain access can be used with og on a single site to map domains to specific organic groups homepages.