Grayside.Org

I wanted to make a CCK Field available only when a given feature was enabled. It turns out it’s really easy.

CCK comes with a hook_field_access() hook (see content_access()). Any implementation of this function that returns FALSE for a given field results in that field being denied to the user.

By implementing this function with a Spaces API call instead of the content_permissions module approach of a new, field-specific permission, all kinds of magic becomes possible.

Read on for demonstration 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:

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

There are two ways to change contexts. The new awesomeness is to use Features or other exportable techniques to create a new version of your modified contexts, and push the old ones out of the way.

However, when I avoid hacking [atrium] core, I prefer the old way—today that’s alter hooks.

If you’ve delved into some of the enhanced bookmarking magic in Firefox, you know that entering the world of the Organize Bookmarks tool provides some additional options in how you save your bookmarks.

Custom Keywords are really neat. I use them for Drupal reference all the time. It’s my preferred method for bouncing around CVS, the API, and issue queues. Typing “d6 hook_nodeapi” to double check the ops is very nice. Typing “dcm og” to start researching how og access control works save a page load.

Attached is a drupal-bookmarks.html file that will get you a leg up on the boring process of creating these bookmarks.

It includes Drupal Project, Drupal Project Issues, Drupal Project Usage, Drupal CVS Modules, Drupal CVS Core, Drupal Site search, Drupal 6 API lookup, and Drupal 7 API lookup.

(You can create something similar in Chrome, but it’s not done through bookmarks. Setting up Custom Search Engines is very similar, and I don’t see an easy mechanism for exportables.)

Attachment: 

drupal-bookmarks.html.txt

If you want to make an exported [node-based] View smoothly integrate with Spaces, you can use the following code to modify the View structure with the “Content in current space” filter. This filter does nothing if the View is not itself in a Space, otherwise it restricts all results to content in the same space. Add any conditions you want to control whether the Spaces integration is applied.

I’ve been looking for some decent ways of managing the use of modules hosted in random Features Servers. Particularly, how do I use Drush as seamlessly with a Features Server as it works with Drupal.Org?

It turns out that Drush has a lot of special options buried in the pm-download (dl) command, the very Drush maneuver most helpful for my goal. Naturally, these options can be included in a Bash Alias for Drush.

I’m not a huge fan of the Automatic Nodetitles module. It’s got a lot of user interface overhead, and yet I’ve never given a non-programmer access to that administration page. On top of that, someone gets a headache from it on one of the forum sites I frequent every few weeks.

For those with the programming chops to avoid it, why keep the overhead of an entire project, when a custom module snippet will probably be more than enough?

Working on integrating the Features Server feature into OpenAtrium. My intention is to set it up as another Casetracker Project type.

OpenAtrium provides a solid case tracker and documentation system, and is a natural fit for the infrastructure of a Drupal.Org-style project ecosphere. Integrating them will allow me to post Features I’ve created to a place where I might actually have a means to get feedback on my work, let alone provide support.

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.

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.