In my previous Headless Drupal post, I proposed ways to work with Drupal content programmatically, particularly for bulk tasks like updating many nodes.

But, in that post, I conveniently only covered plain vanilla Drupal nodes; what if the nodes you need to work with have CCK (Content Construction Kit module) defined fields? These are specified through Drupal’s administrative GUI, and so, its not obvious how to programmatically reference them.

This post will show you the way that I commonly deal with this situation, and I’m embarassed to say, it relies more on knowing a few Drupal tricks than any deep knowledge of the inner workings of Drupal. But these methods easily and reliably show you how to programmatically reference, access and change CCK defined fields just like any other node attribute.

In my previous Headless Drupal post, I proposed ways to work with Drupal content programmatically, particularly for bulk tasks like updating many nodes.

A question was raised in a comment on that post as to how to use that information to migrate content between instances of Drupal, and in particular how to handle file attachments on nodes, especially if they are large.

I have to admit that I haven’t had to solve this exact problem often, and when I did in the past, it was with basic page nodes. My initial reaction is that the techniques explored in my Headless Drupal post may not be the best fit for this task. I view this task as a basic import/export problem, and from my past experience, I know of contributed modules that specifically address this need, so I decided to reacquaint myself with them in an effort to provide a set of options for solving similar problems.

Whenever I work with a significant framework or off-the-shelf software, I invariably encounter situations in which I need to do “one-off” programmatic batch tasks outside the normal flow of the application.

Today, I will explore how to do some programmatic manipulation of Drupal (specifically Drupal 6, although this approach is very similar in Drupal 5) showing specific examples to get you started creating your own scripts.

In one of my earliest blog posts, I described an approach to customizing a search form that I employ on many of my sites. Instead of having a search form that consists of three elements: a label, text input field, and submit button, I like to reduce everything to just the text field with the label inside it, as you can see on the right hand column of this very blog. This frees up room, and requires less mouse work on the part of the user.

I originally saw this basic functionality on the Mambo CMS site, and because I don’t like to needlessly duplicate work (otherwise known as laziness), I decided to completely and shamelessly rip off their source.

More recently, however, I have been using jQuery and have been moving toward implementing Javascript unobtrusively, and so, I decided to explore re-implementing this approach accordingly.

I recently built a Drupal site for a small (individual) client who wanted to host the site on a Network Solutions basic Web hosting plan. This made sense for him, because he had registered several domains with them. He wanted to keep things simple, which is always my goal too. We weren’t anticipating tremendous traffic, etc., and ongoing costs were a consideration, so this conservative approach made sense.

I had never used Network Solutions before, but thought I had heard generally good things about it. I double-checked what came with the basic hosting plan, and everything looked fine.

Then the day came when I actually tried to implement it…

I continue to find useful the script I posted some time ago that creates a basic site structure in Drupal. Its not uncommon that a customer will want a leg up on migrating their content into Drupal, or will have a basic structure in mind even before they fill it with content.

I recently started working in Drupal 6, now that many of the modules I typically use are at least in beta for Drupal 6. So, I found that I needed to update the script as follows:

I am starting development of a significant new Web site implemented in Drupal, and have as my team five talented, but relatively inexperienced, developers with little existing knowledge of Drupal. This is my attempt to provide a quick orientation to Drupal from a developer’s perspective, based on my experience.

A customer on a newly launched Drupal e-commerce site I produced reported the following error:

Please enter a valid ZIP Code for the sender. (error -2147219498) usps configuration error. Please notify the site administrator.

Which occurred during the checkout process and only happened when a zip code contained a “+ 4″ code at the end.

Of course, I often find Google to be the best debugging tool of all, and I quickly found this post containing a workaround by Kenneth Bartlett that not only made it so I didn’t have to untangle the shipcalc module’s code, which would likely mean debugging Web Services calls to USPS, but is actually a pretty good solution in its own right I think.

The only thing I didn’t like about it was that it directly patched an e-commerce module file at modules/ecommerce/address/address.module. Whenever I use a piece of customizable software like Drupal (or Wordpress, osCommerce, etc.) I avoid directly patching both the core code and any third party modules, because this creates a maintenance burden for me when I want to upgrade the core software or an affected module, which could potentially wipe out these kinds of patches. I have my hands maintaining my own code, I don’t want to worry about modules I didn’t write.

When it comes to producing robust applications efficiently, choosing a framework is just the first step. Just as important, is familiarizing yourself with a framework’s plugins and knowing how to use them effectively.

I’ve been using Drupal regularly for about a year now, and I continue to be impressed with it. Not only is the framework itself robust and intelligently architected, but I’ve come to expect that when I need to add a new feature to a site, I can find an existing, mature plugin (or “module” in Drupal’s terminology) that implements it. Not only are these modules great in their own right, but they often work surprisingly well in conjunction with other Drupal modules.

There are so many modules, that it can be a little overwhelming at first. So, although the list of modules I am going to provide is obviously subjective, based on my own use of Drupal, I think it will help orient new Drupal users to some of the more commonly used Drupal modules.

I recently finished implementing a Drupal site that contained premium content, which a user can access only by purchasing a subscription. I am going to describe the general roadmap I followed to implement this, and while obviously somewhat specific to my situation, I think the guidelines provided can be easily adapted to many similar situations.