An approach to creating groups and persistent URLs in Drupal 7

A major project has been exploring the creation of a collaborative space using Drupal 7. Somebody else has taken this over whilst I concentrate on other parts of our system and integration but I thought I would post about the Persistent URL (PURL) creation.

Fortunately Drupal 7 comes with a fair few options which the P2P Foundation has documented  on its wiki.

One of the things that I have been looking at is how to get ad hoc groups of individuals interacting. Organic Groups (OG7 as I use Drupal 7) is a really powerful way of building an area which can be shared by a user and to grant options to create pieces of content from blog posts, Wiki pages and forums.

One of the early issues that I had was to create a PURL for the groups and annoyingly this does not necessarily come out of the box with the module. I came across this in the excellent presentation by Amitai Burstein at Drupalcon in London, “OG7 – this time it’s on” when the person next to me asked how one created Purls in OG7 but there was no real answer. This slightly troubled me but I did not pay it much mind at the time.

The standard way would appear to be using OG7, the Spaces and Purl  modules from Drupal and some of its other requirements. Using Spaces, the developer can build features such as blogs or similar and bundle them into the area of the group namespace. The group namespace can be created in the Purl module and it creates a series of sites within your main site. Having already started building, I was not really prepared on this occasion to change and rebuild from scratch, especially as I was trying to integrate it into an existing site with its own content.

The solution that I came up with was to explore Views 3 and OG7 and to use the tokens supplied in the core when OG7 is enabled and also an experimental module, OG Token, which supplies the last piece of the puzzle.

When OG7 and OG Token are installed and a group type is set up, the group name can be used in the url to create a front page which might be along the lines of http://somehost.com/mygroup. That gives the group “mygroup” a persistent url under which we might want to have other content types, such as forums or blogs or articles, or even some homegrown content types. To associate these with the group, a replacement URL needs to be set up in the URL aliases section. Using OG Tokens allows you to use the [node:og-group-audience] token so that you could set up http://somehost.com/mygroup/articles/[node:title] for a root for all articles belonging to that particular group and the title gives a PURL for the article as well. The group audience is set up by the user when creating the article and the audience is set. The base content type must have this set before the content is created which is outside the scope of this post.

You can use views to make the URL more useful if you take the  [node:title] away and just want to show a list of all articles belonging to that group audience. (Bear in mind that more than one audience can be set for an article.) To get this working, I altered the og_content view which comes from the OG install. Using the OG Group label (the [node:og-group-audience] part of the URL), I set up the following PHP code:
$handler->argument = str_replace("-", " ", $argument);
return TRUE;

This allows me to take the group label and, with  a relationship set up with the Group GID, return all items belonging to that group. Using a second filter, I can then limit it to which ever content type that I want to show. An easy way of showing all of these is to use the Quicktabs module (set up a block for each of the different content type) and then you can display an AJAX block on the group homepage to show latest content.

So why use the group ID rather than its name? Very simple. If you can two groups called my group, the URL is mygroup and mygroup-1. However OG does not appear to store this so calling the mygroup and then trying to search on mygroup in the database could reveal content that belongs to the wrong group. Embarrassing at best but it could also expose confidential information if one or both groups are private. Munging the URL and returning the ID means that the correct content belongs to the correct group.

For my purposes, I wanted to create some simple content types which a user can utilise to create content for any group that they wish to (providing that they belong to them) and to share them without segmenting the site into subsites with similar features in each one. Using tokens has allowed me to do this and to maintain some separation of content using views. It also means that I can set up URLs which return relevant content at each section as well in the hope that I can use this to help the user discover content as well as having groups be discoverable and persistent.