It's fairly common to have a development site and a live site running at the same time - whether it's a Drupal 5 to Drupal 6 migration, or simply a development environment for test features before running them on the live site. In any case, one of the issues that comes up here is that the content on the development site can quickly become out of date. This is an issue if your development site will eventually become the live site, as in the case of a D5->D6 migration process.

OpenConcept has used a number of solutions for time tracking and project management over the years; Basecamp, along with a couple of iterations of a Drupal 5-based system based on the Worktracker module. OpenConcept has grown considerably in the last couple of years, and with additional staff, bigger projects, and the historical accumulation of information each system began verging on unworkable as we transitioned to the next.

Recently we built an event registration and online payment tool using Ubercart and the Webform module, based on Drupal 6. There are a number of options when in comes to Drupal-based event registration - the one we've used before is CiviCRM's CiviEvent. Of course, in this and most cases, the CiviCRM suite is overkill and adds far to much complexity when CRM functionality is not required.

Ubercart is definitely the module of choice when it comes to accepting online payment through your own site. However, at the moment, the de facto Ubercart method for doing online event registration is with a module called UC Node Checkout. It's perfect for a one-and-done event registration site, but for a site that is hosting several events simultaneously and on an ongoing basis, it's awkward. This is due to the fact that it maps a content type to a product SKU - so for each event you'd need to create a new content type. Not really very good long-term, particularly when the site administrator is not overly familiar with Drupal or Ubercart.

One of the more interesting DrupalCon DC sessions from my perspective was one describing the in-progress core Fields module. It is heavily based on CCK and will replace CCK in Drupal 7. The development is ongoing and has benefited from a number of recent code sprints.

I'm excited about this module for a number of reasons. First and foremost, it will allow fields to be added to any object- not just nodes. This includes Users, Nodes, Comments, data pulled from outside sources - whatever. Needless to say this is going to be very useful, potentially replacing modules like Profile with core functionality.

This is done through some carefully thought-out APIs that will once again change how custom field types are created, though hopefully for the better. According to the presentation (found below) it's a return to the data level/GUI level pattern found in D5 but departed from in D6. Probably the very best part, however, is that the API documentation will be included in core and will thus be accessible.

Recently I've undertaken researching various options for accepting credit card payments for Camp NeeKauNis, a non-profit organization I'm heavily involved in. We wanted to be able to accept donations and camp fees through our website, moving from mailed-in paper registrations and cheques to online registration and payment.

On the site side, CiviCRM provides us will all of the functionality we need - all that it needs is a payment processor. CiviCRM already supports a number of processors - PayPal, Google Checkout, Moneris, Authorize.net and more.

Ubercart, a Drupal module designed to add e-commerce to websites, is our de facto choice for adding such a feature. I've investigated the support for these payment processors out-of-the-bod - of course, you can always create your own module to support a new processor.

Project Page: http://drupal.org/project/node_form_rearrange

Recently I've been working on a project that requires the taxonomy selection to be better integrated with rest of the input fields in a node creation/edit form. Normally, for node types with more than one associated vocabulary, a fieldset called 'categories' or 'vocabularies' is drawn up containing each of the vocabulary's selection form element:

Recently the Category module has been causing OpenConcept significant difficulty - see Ron's post here.

We are transitioning this site from using the Category module to using the core Taxonomy module to categorize our content. We're using Views to build pages of content, something that was done by the Category module previously.

The first step in this transition is making sure that node-category relationships are mirrored by node-term relationships. This is a pretty straightforward database manipulation. Here's a script for doing that operation.

Recently, a project I was working on required access control on individual nodes. We used the module Node Privacy by Role which allows for view, edit and delete permissions to be set per node, per role. While this process is time consuming, it allows there to be levels of content that can easily be edited by administrators. Since Drupal has been moving toward user-defined content types, rather than types specified explicitly by modules, there are few options for adjusting permissions by the standard way (Access Control for Drupal 5, Permissions for Drupal 6).

Updated Dec. 18, 2008 (notes in bold)

Recently we set up a wiki for a client as a tool for collaborative documentation. They are running the new version of Drupal, 6, which includes some changes to content types, modules and so on. In this case, the wiki content had to fit in with page, blog and other content without missing a beat.