Grayside.Org - features

Features Module, Then, Now, and in the Future

Grayside — Wed, 28 Mar 2012 21:03:03 +0000

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.

Unfortunately, there is no standard for doing this, so Features develops a mechanism for wrangling exports. This is sad, because it confuses the use case of the Features module itself.

Now

Unless you are active in the Distributions movement or style of site-building, the sense I get is that this is a common thought process for those that run across Features:

I need to toss my configuration into code so I can ship my website around. This Features module things has traction. Darn, the UI sucks, I have to click all these little boxes. And all these info hooks, info alter hooks, and caching layers complicate my day.

Meanwhile, in #drupal-features, a paraphrase:

We totally need to get the exporting out of Features. It adds complexity and attracts all these irrelevant use cases to the issue queue.

Future

The Configuration Management Initiative is exciting. From the perspective of a Features user and developer, it finally defines the standard and mechanism for configuration. That means Features finally has a target for how to pull the out-of-scope pieces out.

After several conversations at DrupalCon, I’m expecting we’ll be seeing a 2.x architectural branch for Features that drops the export stuff. That doesn’t mean it will become an inconsequential module–it turns out capturing use cases in configuration is surprisingly complex. People do not agree on what bits and pieces naturally fall together. But that’s okay, because we are reviving the Kit specification. Expect more from me on that in the future, I think standards like that are key to keeping Drupal intuitive as the Distributions-driven approach to Drupal continues to accelerate.

Terms:

features

drupal

cmi

Integrating Some Other Feature with Spaces

Grayside — Fri, 23 Jul 2010 16:10:17 +0000

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:

I have the FeatureServer feature.
I want it in OpenAtrium.
Here’s a new Feature that provides some Contexts and some Groups variables.
Here’s a patch that you must apply to FeatureServer to make Spaces aware of it. (And other stuff).

#4 is a pain, but I’ve recently discovered how to shrink it down a little more: hook_system_info_alter().

/**
 * Implementation of hook_system_info_alter().
 */
function my_atrium_savvy_feature_system_info_alter(&$info, $row) {
  if ($row->name == 'some_other_feature') {
    $info['spaces']['types'][] = 'og';
  }
}

This hook is called from features_get_info() in features.module. The hook allows you to changes all the info files settings of a feature. Note: Row is apparently a huge variable to dump to the screen.

Terms:

openatrium

spaces

features

cat kit | specificity

Grayside — Tue, 01 Jun 2010 06:52:43 +0000

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?

The answer boils down to this: Keep your Feature lean and mean. Include only what’s necessary for a good, mission-complete piece of functionality. The primary reason for this rule strikes me as the worthy goal of avoiding a horde of bloated, conflicting Features that will make an ill-configured wreckage of the sites that try to use them.

Behind the fold for further thoughts about what specificity means in a well-built Feature.

In thinking about it further (and the way I’ve used Features so far), I found a couple examples of why specificity is worth thinking about.

1. The Over-Configured Content Type

I created a Feature around a new content type. The Feature itself related to how that content was listed around the site (a couple of Views). I exported every variable related to how I had configured the content type, even though my Vertical Tabs settings had no specific relevance to the functionality I was seeking to isolate and export.

For an internal-use sort of Feature, I’m sure this does not matter. (Unless you are trying to define all your Vertical Tabs settings in a different Feature). For a publicly-shared feature, you have now introduced a piece of Vertical Tabs configuration which really has no bearing on the reason someone else might have been interested in your Feature.

2. It’s How I Use It

People disagree on how specialized any given modular website nugget should be. Just look at all the Drupal Modules with overly-themed defaults. Kit specificity in a Feature means the Feature includes only the aspects of theming and site integration necessary for the Feature to make sense, not that your specific use case for that Feature is realized in a shiny exported module.

For internal-use… go for it! Kit is clearly intended as a standard for the growing world of shared Features. Exportables purely for deployment facilitation need not apply. Of course, Kit-compliance from the get-go will surely help you make the unlooked for transition to a publicly published Feature much easier.

Terms:

drupal

features

kit

cat kit | summarize namespacing

Grayside — Sun, 23 May 2010 06:03:15 +0000

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.

Code Namespace

Covers: Filenames, function names, directory name.
Rule: Make the namespace (prefix) unique.

> Domain names and Drupal.Org user names make good prefixes. Why? Because they are guaranteed unique by an external authority everyone in the Drupal community is bound to bump into.

Project Namespace

Covers: Project name, as defined in .info file and a Features Server feature node.
Rule: Same as the code namespace for a single-feature project.

Machine Name

Covers: Generic part of the feature name.
Rule: Should be short and descriptive.

Features will generally be called <namespace>_<machine name>.

Human Readable Name

Covers: Name of the feature, such as on the modules page. (As defined by name in .info file.)
Rule: Skip the namespace. Stick with a descriptive name.

(I interpret this to be a human-readable version of the Machine Name.)

Component Namespace

Covers: All the bits that are exportable. (Views, Content Types, Rules, etc)
Rule: Prefix with the Machine Name.

Example

Here are the namespace selections for a project enhancing the OpenAtrium Notebook.

Namespace: grayside
Project Name: grayside_oa_book_manager
Machine Name: oa_book_manager
Human Readable Name: OA Book Manager
Component Namespace:
- View: oa_book_manager_bulk_update
- Rule: oa_book_manager_new_page_message

Terms:

Feature Server: Not That Hard

Grayside — Fri, 07 May 2010 06:27:40 +0000

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.

It slid into this blog site very easily, and now I have a very clean way of upload and sharing Drupal code and functionality snippets. But should I leave the fserver as part of my blog? The last thing I need is to release a couple popular features into the wild and have to worry about the Update Status module pinging my words to death.

Terms:

features

features-servers

Drush and Features Servers

Grayside — Sat, 01 May 2010 07:14:15 +0000

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.

For those who need more catching up:
Features are a special kind of Drupal module built on the features project. They allow you to easily export configuration from your site into a module usable on any site. Modules downloaded from a Features Server are the next best thing to one posted to Drupal.org. DrupalConSF has a great video.

Current State

The rise of Feature Servers, and perhaps other types of code release repositories would benefit from a little Drush magic. The little-documented option of –source is a starting place:

drush --source=http://code.developmentseed.org/fserver/ dl fserver

This code will grab the latest, most recommended release of the Feature Server code from DevSeed’s feature server.

Future Directions

I’ve started an issue in the Drush queue to talk about some kind of repository scheme to help manage the download and file placement of code from individually preferred repositories.

Terms: