Grayside.Org

I have just tagged the first OG6 release since March of 2010.

We have a fine assortment of changes (see the changelog), ranging across:

• New Hook API Documentation
• Views integration improvements
• Localization improvements
• Miscellaneous areas of moderate interest

This release locks in some changes, clarifies the status of Notifications (sticking with the 2.x line for now), and sets up OG6 for a stable position to start looking at what should happen next. I’ve posted a sort of maintainer’s philosophy position on how I see OG6 moving forward, you can read it at the d.g.o address of Organic Groups. What does all that translate into for my next steps?

Well, aside from a few clear cases, it’s still very much up to the community. I’m going to focus on a few good patches, and see if I can help the groups.drupal.org-related issues, performance, and the Weirdness subqueues. I’m hoping to have enough cool stuff pulled together to release 2.3 in honor of Drupalcon Denver.

Please, keep in mind this post was written for Drupal 6 and Views 2! D7/Views 3 sites might not take so kindly to it.

Recently I was looking at creating a new Todo Feature with a due date. I cracked open CCK’s manage fields UI and added a date field, careful to keep in mind that the default value should be no date, which just happens to translate as NULL. You see, for my Todo use case, not all Todos would have a deadline.

My next step was to create a View of all upcoming items. I wanted the next most urgent todo to float to the top of the list. Sadly, NULL counts as 0 in database land, so my carefully clicked Sort was preloading all my urgent todos with all the lowest priority tasks.

Seeing as this was a SQL problem, I googled the ‘net for viable query tweaks. I found a nice article illustrating exactly what I wanted: MySQL Sort Order with NULL. The grand secret? Sort first by whether the duedate is NULL to flip your empty values to the bottom of the result set.

Read on to see how I added this change to my View.

One of the neat features of Drush is it’s configurability. Setting the defaults for various behaviors and command options allows you to build really simplified, specialized workflows. You can create personal settings defaults by dropping a `drushrc.php` file in one of the places Drush will look, such as inside a .drush folder of your home directory.

The following post originally appeared on the GoingOn.com blog.

After more than a year of continuous investment in GoingOn’s Drupal 6 platform, the idea of upgrading to Drupal 7 is incredibly daunting. We have custom modules from form behaviors down to the access layer, we have features encapsulating hundreds of exported components, and an aggressive feature release schedule that does not set aside 6 months for a complete rewrite of the codebase just for a new version of Drupal. What to do?

We’ve been playing around with the idea of iterating our Drupal 6 platform toward Drupal 7. By pulling markup, design patterns, APIs, and architecture in Drupal 7 down into platform incrementally, we hope to shorten the final leap that will come when upgrading the entire system.

Some months ago I wanted the solution to overriding a Views Field template entirely from within a module. I spent hours trawling documentation and issues, and playing with a little trial and error. In the end, I came up with a solution:

People often seem to wonder how they can get their new date-specified content types to show up on the Atrium Calendar. The following Views snippet makes it happen for a content type called “example_type” in module “custom”. Note that this code is specific to the Views as they were renamed for Kit-compatibility in Open Atrium 1.0-beta8.

I like Prepopulate. I like to have that pseudo-RESTful way of preloading a form to minimize the amount of work a user has to do to get to the point of submitting a form. But I also like clean URLs. This post reviews in detail a technique to use a single prepopulated nodereference field to prepopulate a bunch of other fields based on that reference.

Recently I dusted off OG Vocabularies with an eye toward integration with OpenAtrium. To my mild surprise, there was really not much that needed to be done. The menu path (node/%node/og/vocab) isn’t great, but that can be tackled later.

All I wanted was to avoid another hidden tab that can only be reached by clicking on Settings > Customize Features. I wanted the group vocabularies to be accessible directly in the Settings menu.

I’ve just published the Organic Groups Privacy module to Drupal.Org. It’s an API module intended to help give developers an easy and flexible way to define public access to Organic Groups posts. It exists specifically so I can convince Spaces that I really mean it when I say an arbitrary 90% of an Organic Group should be private.

It is bundled with a Feature that demonstrates how you might integrate it with an Open Atrium site, but the core of OG Privacy can be useful even without Spaces being in the mix at all.

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.