Presented by Young Hahn of Development Seed

Open Atrium & Context

• Open Atrium = open source intranet package, open sourced summer 2009 for collaboration by small teams
• Context: module for triggering reactive behaviors within a page load. Controlling block visibility, menu trails, page classes, and page templates…
• before Context you had to use arguments to figure out where you were in your Drupal site and do stuff based on it - logic about where you’re are is spread out all over your site in little code snippets
• questions like am I viewing a blog node? am I on the blog view? am I on the blog edit form?
• Instead, the question can be “Am I in the blog section”? - insert an intermediary question
• based on certain conditions, you’ll get certain reactions - when blog section is active (conditions), you’ll get different output (blocks, etc - reactions)
• Context in Atrium: casetracker context, casetracker-book (only active when viewing a book page within the casetracker), casetracker-project (only active when viewing a project within the casetracker)
• global context - contexts are always active: atrium-intranet-global (always active, provides sitewide blocks), layout-login (sets a thinner page layout on login, user registration, password lost, other related forms)
• multiple contexts layer together to create one “page”
• Context editor - very handy feature from Contexts 3 in Admin toolbar that lets you edit contexts inline - drag and drop blocks, switch themes and layout options, etc

Groups and PURL

• OA started out using Organic Groups
• How does OG figure out what group is active? Sometimes the URL explicitly specifies the group ID, sees whether the current node belongs to a group ($node->og_groups), or user’s session includes last viewed group ($_SESSION['og_last'])
• Sometimes though those determinations conflict and you don’t wind up in the right group
• PURL - Persistent URL: library for capturing and abstracting request handling that goes beyond what the Drupal core menu system provides. Detection of request components, like subdomain, path prefix…
• demonstration of how Flickr, Drupal internationalization (i18n) do similar things
• Dev Seed took these examples and applied them to groups.
• example.com/planning/node/5 comes through - PURL recognizes the “planning” element and strips it out, passes that to OG, passes the stripped URL to Drupal, but the “planning” element remains
• user agent, domain/subdomain, path prefix, query string - all can be parsed by PURL
• examples of how PURL is used on Managing News, afghanistanelectiondata.org
• PURL is independent of session, login, cookies, etc - truly persistent!

Spaces

• Spaces is an API module intended to make configuration options generally avaliable only at the sitewide level to be configurable and overridden by individual “spaces” on a Drupal site
• A space is a configuration environment that is triggered or made active by some condition.
• configuration object - a drupal site building or configuration structure (variables context and views, not nodes users taxonomy or other content)
• override variables when a space is active; reverts to default when no space is active
• Spaces lets you customize contexts
• Spaces Custom Text module - lets you customize strings on a per-space basis
• controller plugin - CTools plugin that manages retrieval and storage of overrides for a given object type
• controller sits between object storage and loader - loads up things for the active space if they exist, falls back to object storage if not
• spaces preset - set of overrides that can be used as starting template for new spaces
• controller first checks active space, then falls back to presets (for all spaces?), then falls back to object storage

Yesterday I installed Open Atrium for the first time. I’ve been using GoPlan for a few years now and while it’s a great app and has been totally satisfactory, we’d prefer to use something free and open source for project management. And since this is a Drupal shop, nothing makes more sense than Open Atrium.

I downloaded and installed the newest Open Atrium version available (1.0-beta5), did some basic configuration, checked things out and was quite pleased with what I saw. But I noticed that the Drupal core was outdated at version 6.15, and I’m not really keen on running Drupal with security holes, so I set out to update to 6.16.

My first update attempt failed; backed up the old code and my database, installed the new Drupal core code, moved stuff back to where I thought it needed to be, ran drush updatedb, went to my site and saw no styles, no content, and a few error messages. Undid everything I’d done, restored my database backup, poked around on the web for any documentation about updating Drupal core in Open Atrium and found nothing except other folks having problems and looking for help. So I started over and managed to make it work; haven’t worked tons with the site yet so there might yet be something broken, but I figured I’d still post the steps I took up here for my own reference and to hopefully give someone else a hand.

1. Backed up the database and all code (always the essential first step!)
2. (Using ~ to refer to my Drupal root directory) Moved ~/profiles/openatrium and ~/sites out of my Drupal root for safekeeping.
3. Removed all remaining files and directories from my Drupal root directory.
4. Downloaded and decompressed the Drupal 6.16 code into my Drupal root directory.
5. Moved my old profiles/openatrium and sites directories back into my Drupal directory structure.
6. Ran drush updatedb; if you don’t use Drush you can run update.php through your web browser.
7. Pointed my browser to my site, logged in, tested a few things out - all looks good!

Not so difficult; the only thing I did differently the second time around was to make sure that the ~/profiles/openatrium directory was back in place before updating the Drupal database, so I think that was the key.

Hope this helps other folks running into trouble updating core on their Open Atrium installs!