I'm working on a migration to Drupal for a small university, roughly 2500 students and we're trying to figure out how many sites, what deserves its own site and what departments should be mixed together.
I began by using Domain Access but moved away from that when it felt like it would be too hard to keep the different departments' content and users separate. That drove me to multisite, which feels much better. I planned to give the large departments their own site, with their own set of users, menus, events, views, taxonomies, etc. Then smaller departments would live within the larger departments in which they belong organizationally. This would result in about a dozen sites.
Others involved in the project are worried about this though. They are mostly concerned that
a) it'll be too difficult to share content between sites
b) links between sites will break easily
c) all mission-critical data needs to be up all the time
I feel that a) isn't that big of a problem because a limited number of things need to be shared. But definitely things like user profiles, news, events, and some other marketing info will need to be shared. My hope is that it won't be a problem once I get a better handle on using RSS for some sharing and something else like RDF (FOAF?) for other things (or maybe for everything?) I ran into problems sharing specific fields through rss and then pulling them back out on the other end. Suggestions on the best way to do this?
I don't know that b) is such a huge issue as most links between sites would be to the other site's front page and ones that aren't would be given a url that wouldn't change.
c) is a big area where we disagree. I feel that a top level "core" site (www) should only have things like news, sitewide events and calendar, top-level marketing and informational content, and other things that don't fall into any other department. I feel like, as long as we keep everything backed up well and not allow editors to do anything that would take a site down, it's unnecessary to think of one site as the one site that can't go down -- none of them should go down! Therefore, it's unnecessary to pull extra content into the core site simply because it's important. But they disagree and think we need to put into the core basically everything that a visitor needs to see, which means a whole lot of content from different departments.
i know this is a mish-mash of topics, but I'd really appreciate any feedback, experiences, and opinions on the above, especially as relates to points a and c. Thank you!
Comments
Single Sign On module
There is a module called single sign on that will allow your users to log into multiple sites. It's pretty new and I presonally haven't tested it, but thought I'd put it out there.
See:
See:
http://www.trellon.com/content/blog/sharing-content-domain-access
http://geeksandgod.com/forums/dynamic-website-forums/all-about-drupal/sh...
Multisites with the same content, users, ETC.
Hello,
I have come up with 2 solutions to a similar issue.
I have 2 domains:
www.climbcanada.com (main site - custom theme)
www.climbjasper.com (sub site - custom theme)
I had to have the content, users, certain menu items shared amongst both but the domain in the address bar had to stay the same depending on which domain the user was on. The reason is that the www.climbjasper.com site had to have only Jasper specific Content where as www.climbcanada.com encompassed everything.
I knew at the theme level I could make this work but how do do this on the domain level... ???
I played with the domain access modules with no luck.
Here is my blog post on the first way I solved this issue: http://www.ventureweb.net/blog/multiple-domains-one-drupal-install-part-...
Now after I posted the above blog, my coworker informed me (thank you Olly) that you can have multiple sites in the sites directory (this is in the install.txt http://api.drupal.org/api/drupal/INSTALL.txt)
So in my sites directory now has to folders called: climbcanada.com and climbjasper.com (each have their own settings.php file).
Now for the domain point or redirect. I use shared hosting on Media Temple so I followed their directions here for a sym link: http://kb.mediatemple.net/questions/63/Pointing+Multiple+Domains+to+the+...
The second way was a cleaner way then installing more modules. Plus if I have to create a new sub site I can just add a new directory to my sites/ dir.
I hope this helps someone out.
chris
CAS
At the University of Delaware, we use CAS to solve the login problem. Basically we have a centralized authentication server which drupal users go through to log in, bypassing the regular drupal login. There is a Drupal CAS module, but you have to set up a CAS server to take advantage of it. Works great, though.
I'm wondering what issues you ran into with Domain Access that made you say it would be too hard to keep content and users separate. I have played with DA, and did not foresee any such limitations. Have not truly implemented it yet, tho.
On the issue of stability and mission-critical content, I think it makes sense to have a core site that is locked down pretty tightly in terms of what users and admins are permitted to do. Smaller sites could then crash without bringing the core site down. No matter what you do, you need to put up testing sites where you can try out new modules without impacting any of your production sites. I hate to say it, but you probably need a testing site for each production site. Maybe that's crazy talk, but I'm afraid it' not. Kind of makes you think twice about putting up a large number of sites that could potentially have ongoing theme or module changes.
At UD, we have a production server that is tightly locked down, and anyone can request a site on it. They get centrally approved modules and themes there. There is also a development server that you can play on just to get set up with a theme you like. Once you move to the production server, you aren't even allowed to access the themes folder, much less the modules! This is intended to keep all centrally supported sites stable. Anyone who wants to be able to take advantage of the full power of Drupal is on their own. I don't think it is a perfect solution, but we are new to this and that's where we are right now.
Do you think it would work to
Do you think it would work to take both a standard multisite and a Domain Access approach? So maybe the languages department has their own multisite site, but that site has separate sites for English, Spanish, German, etc provided via Domain Access? That might get confusing, but it would allow for both firm separation of larger departments and loose separation of departments within that department, if that makes sense.
Be cautious when sharing data via RSS or something like that that you're not making something publicly accessible that shouldn't be.
I agree that link rot is not an issue on a Drupal site unless there's something strange going on, and also agree on your position on downtime. Actually, segregating content across separate sites should lead to less total downtime, not more, due to the ability to only take one site down at a time when something needs to be worked on. That is, it's less likely that tweaking something for the History department will require taking the Psych department's site down.
The Boise Drupal Guy!
My experimentation with
My experimentation with Domain Access was about a year ago, and I've learned a lot since then so maybe I'd be smart to look into it again. But I felt like I was having to put a lot of work into making different menus and blocks for the different sections, and even more work to make sure some customization I did for one domain of the site didn't conflict with something I did in another domain. Bad planning perhaps, or maybe I was just doing it wrong, but that was my experience, and going full multisite felt very freeing and less complicated.
I am using Aegir to handle the multisite setup. Kind of a pain to get going but definitely makes me feel better equipped to handle many sites. Because of this, I'm not sure using domain access with multisite will work for me, mostly because of the automated handling of domain names and such. Might be fine, not sure. It's an interesting thought though.
Good point about RSS. Yes, I won't share anything that way unless it can be fully public. I'm still curious to know how people are sharing complex info between sites though. Seems that having data structured via rdf might be necessary to keep different fields separate in the communication between sites -- have had trouble in the past doing that with rss, though i'm probably doing something wrong. I'm having some trouble getting Views Datasource to work. Thanks for all the advice/comments!
Just want to add on here that
Just want to add on here that after a lot of experimenting I finally got sharing working with RSS. The method, as described elsewhere on d.o, is to make an rss feed view, control the output with contemplate and xml_elements, pick it up on the other site using feedapi, and map it to fields with feed element mapper. Though it said clearly in other threads that this worked, I could not get it to work until I had all of the pieces set up correctly, but now everything's great!