Grayside.Org

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.

Step 1

Build your “example_type” content type. You can build this out however you want, but for the purpose of this post you need to add the same field_date that the Event type uses.

Step 2

Why Not Override the View with Views UI?

Once you have overridden the core Views in Atrium, you take a potentially stressful upgrade/maintenance path and make it vaguely nightmarish. Your changes will disappear into the ether when you upgrade. Restoring your changes would require building out a site based on a backup database to grab the key pieces of your override.

By keeping these changes in code, you can much more easily determine how to fix them… assuming any changes are even necessary!

Happy calendar hooking.

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. Since Prepopulate’s recent 2.0 release, it because a whole lot more difficult to use the Form API to work magic on what it provides.

I use this in conjunction with nodereference to tailor node forms for their relationship with the referenced node.

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.

It turns out it’s really simple. There is a hook.

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.

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.