Grayside.Org

One of the little conundrums in OpenAtrium (and I imagine in Spaces) is building static content for the space. (Or in OpenAtrium terms, getting a nice dashboard box to stay put, yet be customizable by group.)

There are countless ways of doing this, but I opted to create a CCK Textarea field in my group content type (named field_group_welcome_message) and turn on the PHP filter.

Then I created a Box (which is what OpenAtrium uses, could just as well have been a block) using the following snippet:

Previously, I discussed how you could move CCK fields into the node form sidebar by careful fieldgroup naming.

If you are of a programmer's bent, you might instead try the more flexible programmer's solution--preprocessor function. I dug this out of the atrium_blog feature.

Do you like the large gray "Add Blog entry" button when you first visit your blog space, and have yet to create anything? Creating views with similar buttons (or adding more) is really easy!

The key is to create Empty text in your view using the Full HTML Input Format. Then, drop some HTML in like this to make use of Atrium's built-in theming.

The Prepopulate module works some great magic to preload forms from URL variables. But suppose you need some extra magic to modify the titles it puts in place?

You can always use hook_form_alter (and here is one of countless little tutorials on that).

If you already know about that, you might be someone that enjoys the use of hook_form_FORM_ID_alter(). If you do, you cannot use it to override Prepopulate-set fields. It turns out that regardless of module weight, hook_form_FORM_ID_alter is called before hook_form_alter for any given form, meaning that the more specific function will always set the value, then Prepopulate will come along and reset it to your URL value.

There is a nice issue (#300481) that details this problem, and hopefully will find itself fixed in Drupal 8.

You might wonder how cases are considered "closed" for purposes of case filtering in the Case Tracker. It's an attempt to be helpful on the Case Tracker's part– hide the stuff that is no longer relevant unless the user specifically asks for it. Unfortunately, I don't like the defaults on what it considers irrelevant.

The Case Tracker project provides a fairly straightforward issue tracker. In the future it will provide more functionality, but for now certain types of customizations are left to the end user. This post describes an attached module that provides a simple up/down relationship to Cases using CCK.

Attachment: 

Case Tracker with Subcases

This post briefly evaluates the available modules for Drag-n-Drop File Upload & Management in Drupal. Quick summary: It is a sad and sorry thing, with most of the long term solutions in an infant state, and the mature solutions declining or in need of a massive overhaul to stay relevant in Drupal 7.

There is a fine tutorial on drupal.org describing How to set the disabled attribute of a CCK field on your node add/edit form. All that does is deactivate the input widget without removing the clutter. Let's get rid of the form elements entirely.

Janak Singh had a great introduction to tailoring Nano for use with Drupal. Here are the details of how I use Nano.

Attachment: 

Drupal Syntax Highlighting for Nano