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.
Comments
< 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.
The Boise Drupal Guy!
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
--
/thomas
T: @tsvenson | S: tsvenson.com
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.
The Boise Drupal Guy!
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/
--
http://ken.therickards.com/
Big thank you, that is what I needed!
Hi Garrett,
Thank you for bringing this one up.
I'm going to be building two sites for sister-firms which are sharing a lot of content. This seems to do the trick.
Robert Broen.
Dutch based Drupal developer and all-round Kentucky enthusiast.
Heh, my answer was three
Heh, my answer was three years old, but it still stands - Domain Access is the sanest way to share content and/or users between multiple Drupal sites. I've been working on another major site which makes use of it for much of this year, actually, and learning its ins and outs better than ever.
The Boise Drupal Guy!
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
knaddison blog | Morris Animal Foundation
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.
--
/thomas
T: @tsvenson | S: tsvenson.com
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/
--
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
--
/thomas
T: @tsvenson | S: tsvenson.com
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
Frank
My LinkedIn profile
Im using virtual sites, using
Im using virtual sites, using different languages, and it works fine. www.dance-montreal.com and www.montreal-danse.com are just 2 of about 12 sites currently setup virtually.
And yes, it is very easy to set up. They all use the same data but use location and views to localize the data.
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/
--
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.
t: @charyorde
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…
The Boise Drupal Guy!
@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.
t: @charyorde
You're welcome! Glad I could
You're welcome! Glad I could help! :)
The Boise Drupal Guy!
OK, but now all the extras?
The idea:
1) a central server running all the drupal daughter sites from one install.
2) every site has its own user1, own admins, own editors and in no way a daughter can mess up with the central site.
3) every daughter site can and should have their own mirror/backup.
4) every daughter can have their own fully or partly separate database.
5) a daughter site can have a different selection of the central sites modules activated.
6) CiviCRM, groups and intranet can both be exchanged, or completely separated.
7) even within a daughter-site; information can be separated per (civicrm/intranet) group, like separated database.
So let's say a central Independent Media Center for Central America and Caribbean. Then up to 50 country (&island-countries) daughter sites. Then some countries have daughter sites too, so grand-daughters. They all have social orgs with intranet and civicrm and groups. Information is not allowed to leak, so should be separated from other groups and sites if&when requested. News-articles can be exchanged. Information can be exchanged, but only when permitted by individual groups and sites. They all need to have the possibility to have an individual mirror site & backup.
Oh, yes; then maybe running some sites from the same install that have less or nothing to do with this network, like a software development site and maybe some not-connected private site...
quick question about DA and context
Why not to use context, spaces, features and purl?
Could you elaborate?
I'm trying to wrap my head around how context,spaces,features, and purl could accomplish all of this. Is there a pointer on this 'strategy' anywhere?
you can set a context per url
you can set a context per url or domain. With spaces you can set a diferent configuration and variabler per context. Features it's needed for spaces and can give funcionality per space. Purl helps in showing information per site. You could have a taxonomy with the sites to manage audience in contents
( http://sf2010.drupal.org/conference/sessions/heart-open-atrium-context-p... )
I think it's possible, but never tried. Maybe somenone have done something related ...