PURL and/or Spaces?

Question

My site is to have a section for normal users, a section for managers, and a section for use only by anonymous visitors. Each section of the site requires changes to Drupal settings for using a different theme, changing the Primary & Secondary links, changes which blocks are used, etc. In other words, the user experience changes significantly from section to section.

I could probably accomplish what I need by using Drupal's multi-sites, a shared database, and using settings.php to override the variables I need to (ie: menu_primary_links_source). However, to make things more manageable from an operational point of view, and to buy flexibility, I'm considering using the PURL API (purl.module) to prefix the URLs for certain site sections, and having my theme and custom modules react according to the current PURL prefix.

Before I get started, I want to ensure I'm not discounting Spaces.module. Spaces uses PURL, Features, and Context (which I'm also currently using for my site). I don't entirely understand how exactly Spaces fits into the picture. Would it help me make different site sections, each with specific configuration & behavior? Or am I better off depending directly on the PURL API?

Answer 1

The Spaces-PURL-Context conundrum. Fun. I've been meaning to write this up long-style to finish wrapping my head around it.

What is Spaces?

Spaces is a module that creates containers of overridden configuration for your site. It's not specifically about features, it's about any number of configuration values that are able to work with Spaces, including whether a Feature is active or not. (Active does not mean the module is disabled, just that a number of Feature-oriented things are whisked away, such as content types and Spaces-aware Views.

When using Spaces, you need to decide what type of "buckets" you want to use. Open Atrium uses OG and User-shaped buckets, what you need is a new sort of bucket based on user role. For the sake of sanity, you might even need to create a separate module just to define user roles as a more concrete thing in Drupal, kind of like how Spaces OG needs to lean on Organic Groups for a number of concepts.

What is Context?

Context is ultimately a page decorating mechanism. You tell it some stuff about the page, it modifies the page accordingly. Context cannot modify the URL, it's the other way around. Features define Contexts to tell the site how to render a given page uniquely for that Feature, there is no direct connection between Context and Spaces or Context and PURL.

What is PURL?

PURL is a method of sticking things in the URL and keeping them there until you are done with them.

How this Glues Together

Spaces with PURL integration are triggered based on one of two things: The URL or something about the content in the page. To explain this, I'll use Spaces OG as an example.

1. You click a link. The link was prebuilt with a PURL component that Spaces OG is watching for clues. If that piece of the URL makes sense to spaces, the Space is triggered.
2. All links except those that opt-out of the PURL modification persist the PURL URL element, meaning the Space is happy, and re-triggers with each page load.
3. Spaces OG knows to check nodes for their group affiliations. If Spaces can crack open a node and find a group, it will trigger that node's Space, using PURL's modified version of drupal_goto() to redirect the whole page for URL consistency. This will trump any existing URL structure.
4. If there is no URL component, and the node has no group affiliation, no Space is triggered.

Once the Space is triggered, all of that Spaces configuration values are pulled into play. This will mean the Space's preset defaults (you can have multiple default Space configurations for every Space type) overlay Drupal's defaults, which in turn are overridden by any configuration saved specifically for the Space. In the case of Open Atrium, this includes such nice things as group color, blocks on the dashboard, and enabled Features.

If the user goes to visit something provided by a Feature--a Node, a View, etc, any Contexts related to that node, that view, that URL that any module provides might just be triggered, and start doing things with blocks and theming to tailor the page for the Feature's content.

Next Steps

As I mention above, it sounds to me as though your first step is to try looking at Spaces OG, and rewriting it to be centered around the User Role instead of Organic Groups. You shouldn't have to do much with PURL directly besides a little copy and paste from Spaces OG. You might want to post in the Spaces issue queue to float this idea where the maintainers might see it and give pointers.