OpenAtrium and You: A Guide

A few weeks ago I was tasked with developing an Intranet for a client of ours. We decided to set them up with an instance of OpenAtrium, a Drupal project from the guys over at Development Seed. It's a fairly new project, but what I've seen has really impressed me. I won't use this post to detail the pros and cons of the system (that's for another day, after we've had time to really test it out), but rather will guide you through the process of getting OA set up in the first place, and then in the next post I'll show you how you can expand its capabilities using Features.

Installing OpenAtrium as a Subdomain

One of the requests from our client was that users be able to log in at either the OA site or main site, and that for as long as they were logged in to one they'd be logged in to the other. The kind folks over at #open_atrium on IRC recommended I check out a Single Sign-On system called Bakery. Bakery is currently used on Drupal.org and groups.drupal.org to allow for exactly the functionality our client had requested - you log in on a GDO site and are then automatically logged in on Drupal.org and any other GDO sites of which you may be a member. I downloaded and installed Bakery on both the main site and OA, and turned them on. And then my login forms disappeared, and I couldn't log in to either site at all. Lesson learned: while Bakery sounds really great, it is still in development and does not have a stable release available at present - use at your own risk. So, scratching Bakery off the list, I went with Plan B: Share tables across instances. Let me start off by acknowledging that, yes, this method has the potential to break your site. But, for our specific instance, it turned out to be a great solution. I knew that Drupal had the ability to have multiple sites installed on a single DB by way of $db_prefix. What I didn't know was that, as described in the link above, it's totally kosher to specify which tables get the prefix treatment, and which do not. This is perfect for our particular case, as we didn't really care about anything other than the session-, user-, and profile-related tables. Here's how we did it:

1. Drop the full OpenAtrium folder contents into either a subdomain directory or (as was in our case) a subdirectory on your main site. For the purposes of this post we'll assume a subdirectory, and give it the path example.com/atrium.
2. In your favorite instance of VI or whathaveyou, head to example.com/atrium/sites/default and edit settings.php - scroll down to $db_prefix = ''; and change that to $db_prefix = 'myprefix_'; Since we're doing a fresh install of OA, we need these tables to not exist, so we're not going to set our table-level prefixes YET. This part is very important as we do not want to overwrite our existing site's user tables - that would make people very, very unhappy.
3. Once you've changed $db_prefix to something appropriate, go ahead and hit example.com/atrium/install.php and follow the steps. It's very, very similar to how vanilla Drupal is installed, so if you're familiar with that, you shouldn't have any issues. Feel free to create an admin account, enable modules, edit site preferences, etc.
4. After installation and configuration are complete, go back to example.com/atrium/sites/default/settings.php and scroll down to $db_prefix = 'myprefix_'; Here's where we get things rolling. As I mentioned earlier, the only tables we really care about are users, sessions, and various profile_* tables. In order to get your OA installation reading the existing site's user info, just change $db_prefix = 'myprefix_'; to //$db_prefix = 'myprefix_'; $db_prefix = array( "default" => "myprefix_", // the prefix for tables that are not shared. "users" => "", "sessions" => "", "authmap" => "", "sequences" => "", "profile_fields" => "", "profile_values" => "", );
5. Just to make sure we don't have any session wonkiness, it might also be a good idea to head to $cookie_domain and change that to be equal to your base site, e.g., $cookie_domain = 'example.com';
6. Now, save everything and log out of both example.com and example.com/atrium, and then log back in to either site. You should now be able to access both sites after logging in just once on either site. Magic!

Next week: How to go the extra mile and expand OpenAtrium's capabilities using Features.