Grayside.Org

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’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.

Often enough you create a project, get halfway through, and don’t like the namespace you’ve scattered throughout every file and function name. There are plenty of ways to use IDE’s and other tools to change that name, but I prefer the command line.

If it’s a Features project you want to rename, perhaps to make sure you have a more distinctive namespace, you can use the drush command Features Clone. Look for your duplicate (and renamed) feature in sites/default/modules/custom_features.

I’m hoping to find or create a more general solution, not everything you might want to rename is a Feature, after all. If you know of an existing solution please drop off a comment.

update users set pass=md5('NEWPASS') where uid = 1;

I constantly find myself needing to google up a page like this to figure out how to reset a password without troubling the website.

Here’s my own little note.

In Drupal, it only takes a couple hours (or perhaps a couple days) to build the concept of a site-wide content manager into your system. It gets mighty tricky to start parceling out administrative tasks for parts of the site.

With Organic Groups (the module behind OpenAtrium’s groups), the solution to this problem has always been messy. But with the advent of Spaces and Group Administrator configuration, it seems like OA and related sites are within shouting distance of giving Group Managers the power of Content Administration.