Development Seed

Blog

Spaces: A Paradigm for Reusable Drupal Features

How Feature Definitions Interact with Spaces for Robust, Reusable Site Building

We’ve spent a lot of time as a team building similar and sometimes identical Drupal features for different projects. When you think about the Drupal community as a whole, you can just imagine the number of times someone has taken these steps to build a simple Drupal blog:

Recipe for a Drupal blog

  • create and configure the “blog” content type
  • add some useful CCK fields: subtitle, image, emfield, etc.
  • create a freetagging vocabulary for your blog content type
  • create a blog listing view and an archive/tag driven view
  • create a recent comments/most popular sidebar block and turn it on

This takes someone who knows what they’re doing maybe an hour or two. It might take someone new to Drupal much longer. Wouldn’t it be nice if we could package all this up and turn it on with a click?

The Definition Approach

We package features like this by giving them formal definitions. Another way to do this is to translate the steps above into a script and drop it in a module’s .install file, but we’ve found that the definition approach allows us to easily reuse features against different facets of a Drupal site – what we call Spaces.

A space is just a certain slice or facet of your site – for example, all posts that belong to an organic group or all posts by a certain user. When you have a formal definition of what constitutes a feature, you can use that definition to attach that feature to any number of spaces on your site (i.e. Eric’s user space or the Development Seed team’s group space).

We based our group intranet off of this concept. And since each group and user could enable/disable and customize each feature to her liking, we needed a few tools in Spaces to provide functionality beyond what a typical Drupal module provides:

  • a way for a feature to be enabled/disable per space that wasn’t simply turning off the feature module
  • a way to store configuration for a feature per space so that Eric’s configurations were distinct from the DS Team’s configurations

A Paradigm for Reusable Features

Features can be turned on and off for any slice of your Drupal site for which a space can be written. There are spaces modules that integrate against organic groups, users, and taxonomy terms. Now there is also a fourth integrating module that treats your entire site as its own slice – spaces_site.

Spaces site is admittedly a mindless module – where other space types need filtering and routing logic, spaces site has practically no rules. Its main job is to put a feature plug onto your Drupal site. The implications are enormous. Once built, a single spaces feature can be used, enabled and customized on group spaces, user spaces, term spaces, or your entire Drupal site interchangeably.

Spaces, Spaces Everywhere

Once we had our features built, we went to town. Spaces is powering our intranet group and user spaces, the features on several of our client sites, and the features on developmentseed.org itself.

Later this week we’ll show you how to create a Spaces feature step by step from start to finish and how to turn it on on your site.

Impressive work

This solves a real problem. Looking forward to the next article!

Totally awesome

I had the pleasure if spending the morning after the inauguration last week with Eric and Jeff and they gave me a preview/tour of spaces (and a few other things) and I was just blown away. It is still a little tricky to wrap my head around and re-explain, but I could tell that this has the potentially to really revolutionize the way people build drupal sites.

Their solution to “re-usable” elements of configuration is creative and intuitive, it may render the concept of “install profiles” moot, and at the same time provide that desired functionality and bring it within reach of the masses.

The power of Drupal is that

The power of Drupal is that it is made of small bricks of logic (modules). Assembling and configuring these small bricks gives a flexible set of features (your space) adapted to the needs of the site owner.

On the other hand lot’s of people see that as a constraint as you need to master Drupal in order to be able to build the features. (+ productivity)

Forum, is one example. You can make great forums by assembling modules, content types and views. Furthermore you can really achieve sthg totally customized. But it need skills, and this is why you can read everywhere that Drupal’s forum s*ck…

This is why Spaces is really exciting, it bridges the gap between customized and out-of the box features… If I understood well ;-)

Congratulations and keep going…

We do something similar in Aegir.

Modules can provide ‘features’ to the hosting front end, such as DNS hosting and support for multiple web servers, and the like.

This functionality is also similar to the http://drupal.org/project/patterns project, but I like the approach taken with spaces more in that it is a Drupal API, and doesn’t use an intermediate XML format.

Using standard drupal modules also gives you access to the upgrade path and dependency system (ie: you aren’t introducing another top level entity that needs to be version controlled).

I would really like to see something like this integrated into Drupal core for D7, as I believe it’s one of the biggest user interface improvements that we can make, and unlocks an entire new range of uses for the contributions repository.

Congratulations!

This looks like it will save a lot of people a whole lot of time and money. I’m excited to try it out.