Multisites and shared databases
Hi,
I am planning a multisite project where I want to be able to share users and some content between sites.
All sites will be more or less clones of each other, but they will have different target markets (countries mainly).
What I want to do is:
- Use Drupal 6.x
- Have one Drupal installation with many sites
- Be able to quickly deploy a new site based on a master site
- Multilingual support (using the Internationalization modules)
- Share the user database between them
- Give the same user different roles/permissions on individual sites
- Access to all content from all sites, but still be able to control what is visible on each individual site
- Being able to control the languages that shall be available on a specific site
- Different themes for each site
While I want to be able to configure each site individually, I also want to be able to set what will be shared between them, such as taxonomy etc.
At some point, pretty soon, the site will also have ecommerce, mainly using the subscription features to give users access to publish content/marketing material based on their subscription.
Basically you could say I want to have all the possibilities of an individual site, while being able to select what will be globally configured. A bit like it is done in the Views2 module where I can override a global setting when needing a local different configuration.
I have read up on multisite possibilities with Drupal and believe most of this is possible, but it would be great if anyone with experience could give me some advices or simply tell what of the above is not possible.
< blockquote>Share the user
<
blockquote>Share the user database between them
Give the same user different roles/permissions on individual sites
Access to all content from all sites, but still be able to control what is visible on each individual site
<
blockquote>
Sharing the database ist not complicated (content and user), but control also the permissions of pages and users differrent?
Quite complicated. A Solution could be to use an external User DB like LDAP.
What you're describing would
What you're describing would most easily be accomplished with the Domain Access module instead of "true" Drupal multi-site. Check it out - it's pretty slick.
Wow, thanks Garret, Domain
Wow, thanks Garret, Domain Access seems to be exactly what I need for this project to solve many of the items in my list.
--
/thomas
Do you know if using Domain
Do you know if using Domain Access.module hurts performance greatly? I know every module makes Drupal a bit slower, but Domain Access forces the page cache to be switched off because it implements access restrictions.
Thanks,
David Peterson
Honestly, I've never really
Honestly, I've never really considered the performance implications of DA. Even if it disables the page cache, the convenience of what it does is worth it - I'm not so sure it disables the page cache, though… It might be interesting to bring it up in the issue queue and see what DA's author Ken Rickard (agentrickard) has to say about that.
Page cache
No. It only forces advanced page caching off, due to the use of hook_boot().
Normal mode page caching works fine.
--
http://ken.therickards.com/
Block caching is disabled
Block caching is disabled with DA but not page cache for anonymous users. I'm running DA on a Drupal install with over 100 subdomains and it is pushing its limits. As long as you stay in the 2-50 range you shouldn't really have any issues.
hardware/config?
Doesn't the limit depend on the hardware/config? Or are you saying that 100 subdomains becomes impossible regardless of hardware due to the way that the module works?
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
Adding to greggles Q's, how
Adding to greggles Q's, how do you come to that figure? Is it based on traffic or something else?
For the site I am working on it will initially be at least 150 subsites and it will grow continuously to many thousands, if not tens of thousands.
My suggestion is based on both performance and managebility
My suggestion is based on both performance and manageability of such site. You can run up to 50 sites without any significant configuration changes (assuming you have cache turned on for anonymous users).
Once you have 100+ subdomains managing content where some users can post to any subdomain and troubleshooting the issues that arise from this becomes quite complex especially if you are using nodereference fields that are domain (or set of domains) specific. I'm not saying it is impossible - there just aren't enough tools out there to administer content at this point (DA has domain specific content editing but the list gets very very long). There are some modules that I have created to help me out:
- a custom module to create hierarchy between domains to handle domain display (there's a placeholder in cvs - http://drupal.org/project/domain_relationships) and possibly other functionality that's dependent on hierarchy. It's publicly in use on http://www.thebeehive.org/domains for example.
- Domain Blocks (http://drupal.org/project/domain_blocks) to assign blocks to specific subdomains. Block visibility PHP snippets in case of 100+ domains get very messy, plus this module uses hook_db_rewrite_sql() to alter the blocks query.
Block caching is disabled
Block caching is disabled with DA, but can I use something like http://drupal.org/project/blockcache_alter to turn it back on for certain modules?
Thanks.
Expert
I'm the maintainer, but nonsie's the expert here.
The UI elements just were not built to handle more than about 20 domains -- Domain Content, for instance, can break your menu rebuild if you have 10,000+ domains. (Someone filed an issue about that a while back.) And the interface for managing and assigning domains really can become unusable with more than 20 or so. This is just a UI design limitation that can be corrected, if we know where to start.
Otherwise, the issues for DA are the normal scale problems for Node Access modules and, as nonsie points out, the sheer difficulty of keeping straight all the configurations. Though I suppose that may still be easier that configuring separate installations.
--
http://ken.therickards.com/
Virtual Sites
I am doing almost exactly what you describe with the Virtual Sites module. Its a much more lightweight solution than Domain Access and doesn't require all your content to be tagged correctly to work (as DA sometimes does).
I think the only two it can not handle is different permissions per site and different languages.
http://drupal.org/project/virtual_site
Thanks for the tip, looks
Thanks for the tip, looks interesting. Have you noticed any bottlenecks with this module, such as it becomes hard to maintain with a large amount of virtual sites?
--
/thomas
High performance Drupal
You might have a look at these resources:
http://groups.drupal.org/high-performance
http://www.johnandcailin.com/blog/john/scaling-drupal-open-source-infras...
Frank
I need something similar but
I need something similar but limited to just two things. I have set up drupal multisites and am sharing the user tables. I just want to know if there is a module which makes its possible to:
(I have tried Domain Access and it wasn't what I needed since I had some issues with the Feed Aggregator.)
What was the issue with Feed
What was the issue with Feed Aggregator and Domain Access?
I don't know if it was a
I don't know if it was a problem with Domain Access, from what I remember I just couldn't get feeds from a particular sub domain to display on that sub domain, they all displayed on the base url.
DA / FeedAPI
It was very likely http://drupal.org/node/252877, which is a problem for any module (like FeedAPI) that bypasses hook_form_alter().
See the patch -- http://drupal.org/files/issues/252877-execute.patch which is already in HEAD.
--
http://ken.therickards.com/
I'm so glad nonsie and
I'm so glad nonsie and agentrickard are here. DA is actually great but you guys won't believe I'm still looking for a way around DA's problems. According to my findings, I think Domain Block module actually does mess things up for DA. The fact that no matter the number of sites that DA is managing, it will make sure it uses just your default site theme to manage your blocks page which to me is wrong.
I believe that if you can set a different theme for different site using domain theme, you should be presented with a theme specific to that site on the blocks page.
Just my opinion anyways. I believe DA can be better and stronger.
it will make sure it uses
Yeah, block management is a bit weird, but it's not really DA's fault. What you need to wrap your mind around (if you haven't already) is that the block settings are per theme, per site. That means that Sites A and B can each have different block positions for Theme X, and that Site A can have different block positions on both Theme X and Theme Y. In other words, any possible site and theme iteration can have its own different block layout. It's like thinking in one or two extra dimensions than we're used to…
So when you have Domain Block installed and you go to manage blocks on a site, it will switch you to the default theme. You need to make sure to switch to the theme that the site will be using - look for the list of enabled themes above the list of blocks on the block management page, and use those links to switch to the desired theme. Then rearrange the blocks as desired and save the changes. Hope that helps…
@garrett Thanks Garrett. You
@garrett
Thanks Garrett. You have helped me solve a major problem I have been having with DA for the past one month.
I finally realised that i have not been looking at the list of enabled themes above the list of blocks on the block management page. I have learnt that you can manage domain specific themes by just changing to your theme on the block page.
Thank you very much.
You're welcome! Glad I could
You're welcome! Glad I could help! :)