features

Between the issues queue, Twitter, podcasts, and ad hoc discussions, there is a lot of confusion about what the Features module is all about. As someone that has used and developed in it for a long time, I thought I’d lend my perspective. My sense is the maintainers are on the same page, but don’t hold them to this post.

Then

Features is a module to help site builders and command-line gurus easily package up the configuration associated with a specific use case (like a blog), and manage it in code.

I have found more than once a situation in which I had a basic feature that could be used on any site which I would like to see integrated with Spaces (for OpenAtrium magic). It usually runs like this:

When you read through Kit, one of the themes that keeps cropping up is the concept of specific relevance. How do you know when it is a good idea to include a given variable, permission, or other component in your Feature?

I decided a few notes would help me grok the Kit Specification. I post them here in case someone else finds them useful.

Shortest Summary

Project Name and Feature Name should be the same. They should have a nice, unique namespace. The human readable version doesn’t need to show the prefix. Views and other individually exported pieces should be prefixed with the not-necessarily-unique part of the Feature name.

Barely-Shorter Sumary

This summary currently covers the Features Specification 1.0-draft.

It turns out that running your own Feature Server isn’t that complicated. Get a Drupal site. Install the fserver feature. It’s most exotic requirements are Filefield and Context, and context is just their to facilitate easy block placement of release information.

All the feature really does is provide a fancy XML Views style plugin, a couple content types with their CCK fields to specify things like version information, and some special file-handling magic to push files and tarballs around.

Feature Servers have great potential to help structure the use of code sourced outside the formal ecosphere around Drupal.Org this has it’s pro’s and con’s, but I already see their usefulness in providing a little more structure to issue-queue code exchanges and organization-internal modules. So let’s bring Drush into this and boost the ease of use of that usefulness another step up.