Domain as a multisite solution

Thanks for the links - a useful discussion. Apologies for perhaps pressing a political button, I was looking at the comparative rather than the competitive advantages. The article at least illustrates that my uncertainty is justified given the numerous possibilities. I think I need to look a little at TAC to fully understand the issues.

I've just read through the readme and Domain is a remarkable project. In my use case, Domain Access is almost certainly the best. However I'm hesitant due to the complexity and the pre-release status. The difficulties with OG_user_roles is also a stumbling block. The structure of my system is basically:

Portal site
-Event1 site
--List of teams (organic groups using og_user_roles to control publishing)
-Event2 site
--List of teams (organic groups etc)
-Event3 site
and so on.

The functionality required across the sites is similar but not identical.
Permissions required follow the same descending hierarchy - full control down the hierarchy but not up. (i.e. system admin -> event admin -> team admin -> user) so Domain is perfect.

I would therefore not want an organic groups solution for the individual sites.

The existing multisite solution is proving to be a hassle to administer (duplicate content, module configuration nightmares etc) even with only 2 event sites and a small amount of content. The number of sites in increasing so Domain looks like the perfect solution, certainly in the longer term.

Thanks for all your work on this.

Thanks for all your hard work on domain. I'm as excited by domain as I am daunted by how to implement this for a site I'm developing for a charity in my spare time. The existing setup is a multisite install - domain would be ideal to make things easier when adding additional sites, if I can get the design right. I'd be grateful for your comments on how I might implement this using Domain, in particular the permissions and og.

-- ROLES --

Role: Anonymous - comments only (moderate) - Can View all content except private restricted content.

Role: Authenticated - comments (unmoderated), can join groups, revise some content (moderated), may be granted full edit control on some nodes. Can read all content except where restricted.

Role: GroupOwners - role that simply has the permission to create a new group that they own. They then acquire the permissions of a Group admin as follows.

Role: GroupAdmins (group owners and users promoted automatically by group owners through OG User Roles) full control of all posts in any group(s) they are admin, and may publish new allowed content within only their group(s) only (controlled by og_user_roles). Permitted group content types are all cck custom types (5 different types).

Role: SiteModerators - full control.

-- NOTES --

Users who join groups have no additional permissions above the Authenticated role, however they can receive updates from the group about new content. They are basically group supporters who can participate by commenting only on content created by the group admin.

I've heavily customised the organic group module through the use of a custom .po

This basic configuration will be used on each subsite (but not on the main site) but with some changes:
- the content types permitted within a group will differ slightly on each subsite.

ACCESS CONTROL

- The Content Access module controls general node permissions (granting edit privileges, making nodes private etc)
- OG User Roles gives the additional permissions to group admins in the scope of their group only to create content only within their groups.

ISSUES

1) I can not see how to get around my use of og_user_roles and make the design Domain compatible? I've read through the readme and the related discussions but this only gets me as far as thinking I can't use the module, but I'm stuck for an alternative design.

2) I would like to have private site content that may be viewed (and sometimes edited) only by those users who are a group owner or group admin to a group on the same subsite (but not on all sites). In effect, I want to take a peek at the group user role and allow that to extend outside the group to allow viewing. This could be solved by a private group for this content but this adds another layer to those users (they have to become a group admin and join the private group) and it will also be confusing as the custom .po for the group will change the terminology for a standard group which makes it unsuitable for generic purposes.

3) I would also like the option to email all Group admins and group owners on a subsite.

I'd be very grateful for any advice on these. I'm aware that 2) and 3) aren't really domain issues, but it is part of the overall requirements that I need to work out when considering the overall design. Would TAC with a vocabulary containing a term for each group name be suitable for replacing og_user_roles?

Thanks in advance for any advice, Stephen

Case-study - yes, definitely.

I read that thread at the time, and since, but I'm still confused. My problem is analagous to
http://groups.drupal.org/node/4215
However, there is an additional layer of complexity in my use case, in that the 'bands' (or 'teams' in my use case) are grouped into events, with each event having it's own subsite (teams appear in only one event, they don't span across sites). Events can be repeated on the same site i.e. annual events, with new teams.

I agree that TAC is an inelegant way to segregate content across sites, but I can see the value in using it within a site (for example, restricting access to view static content to only teams of a certain year).

Anyway, back to your point, with your node access patch what are the exact issues with using og_user_roles as I described?

I'm reasonably comfortable with the single event/site solution and I'm plodding on with development as and when I can. However, I'm starting to feel as though I'm getting over my head on this and I've made a few approaches to see if I can bring in some paid help (the charity has a small budget for web development) to try and get a lot more functionality into the system, including the multidomain approach. It is only with an effective multisite (Domain style) implementation that the real power of the system will become clear, and that we can offer this as a system for use by other charities and events to 'plug in' to.

Thanks, Stephen

The quote you've used from me essentially answers the question. The OG functionality handles the team metaphor, the Domain functionality handles the event metaphor. In fact, I am looking for OG subgroups to handle the concept of an instance of an Event, e.g. Domain= Football League 1, OG Parent=Football League 1 in 2008, OG subgroups = each team.

Either way, OG subgroups is not really ready for this functionality quite yet see: http://drupal.org/node/234474

Multisite approaches are complex and you have to evaluate your own particular requirements. Domain doesn't handle every situation (and isn't designed to), neither does OG, neither does table prefixing. Combining them all in the right way can, IMHO, solve pretty much anything you have. Domain is an incredibly powerful module that takes Drupal multisite config to whole different level.

This quote above (http://drupal.org/node/212915#comment-753087) illustrates where domain isn't so useful:
"In multisite, the presence of separate dbs means the sites are truly separate and you can easily migrate them anywhere you need"

As a quick and dirty rule, if you're ever looking to share data across multiple sites, Domain is probably the answer, if you're just looking to reuse code and functionality across unrelated (but functionally similar sites) you want old style multisite with prefixed databases.

When we've finished our particular implementation I'll try and do a write up to illustrate.

We've finally launched our site to the public. There is an awful lot more to do, but you can see Domain and OG working together:

http://www.charityrallies.org/

Pages like:
http://www.charityrallies.org/en/teams/all
http://www.charityrallies.org/en/rallies
take nodes from all domains.

These then link out to the subsites where og manages each team, and taxonomy (sort of) handles each event.
http://mongolia.charityrallies.org/en/teams

Og groups together pages from a team and also gives them a team area to enter details.

We've customised the user profiles with Advanced Profile and we've started playing with Panels (but much still to do).

A big thank you to Ken for putting together such an amazing module and providing such good support.

I'll try and do a longer write up when we've got more of the functionality in place.

1. Modules: far too many. the site is heavily loaded with contrib modules. All the usual culprits...
2.Put conditional code in the block visibility like:

<?php
global $_domain;
if ($_domain['domain_id'] == 5)
    return true;  // Display on domain id #5 (Pyramid only)
?>

Sorry, conflicts with DA - yes, there are some but we've either solved them or are working around them. Gmap is an issue - see the issue queue.