Web design, programming, graphics, and pretty much anything else I care about.


Discover CCK field table and column information

When retrieving information from the database for CCK fields, you can't assume the schema. Fields may be added to the content table, but if they are included on more than one content type, they get moved to their own table. Because things might move around, you can't make assumptions about where they will be. CCK api has functions you can use to determine where things are located.

Creating date repeat rules

Because Date doesn't play well with drupal_execute(), you have to use node_save() to insert/update nodes. If those nodes have a date field that uses repeats, you have to manually create the date array and repeat rule. ugh!

Programmatically inserting nodes

Inserting nodes, programmatically, is not always the easiest thing. The "drupally" way of doing it is to build the node form array and then submit it to drupal_execute(). (http://api.drupal.org/api/drupal/includes--form.inc/function/drupal_exec...) This follows the same procedure that the node/add form follows. This method will make sure that all the same validations occur, permission checks, etc. The problem is this is a slow process, and some modules don't work well with drupal_execute; namely, Date. To insert modules that have date fields, use node_save().

Install taxonomy, with terms and hierarchy, on module installation

Getting a module to install a vocabulary, and even import terms, is not terribly difficult; however, getting it to accept an existing hierarchy can be tricky.

(I was working with a taxonomy for academic departments and schools.)

Create an include file. I name them module name.taxonomy.def.inc. In the file create an array that will define the vocabulary, and one that will include the terms.

Configure CCK fields on module installation

You can have a module installation automatically add and configure CCK field. First, setup the CCK fields on a development site exactly as you want them. Then, export the fields from /admin/content/types/export.

You will end up with the code for a php array that looks something like ...

Show block only for specific user or role

A quick and dirty way to control the visibility of a block is to add a php snippet. Set the visibility in the block administration to "Show if the following PHP code returns TRUE", and use something like this:

global $user;
if (
in_array('authenticated user', $user->roles)) {
} else {

I know what you're thinking. There is a setting for making a block visible by role. Yes, but there is no setting for making a block NOT appear for a role. Take the same code and return FALSE for a specific role, or return TRUE for a specific user, etc.

Drupal 6 module development skeleton

At our Central NJ drupal group meetup, and went over some module development basics. The shell of a module I worked on I posted in the groups.drupal.org thread. http://groups.drupal.org/node/104919#comment-353479

Javascript for showing and hiding form fields based on the value of another field

This is the rather long js for making a block of fields only appear if a specific value was chosen for another field. (It made address information appear if you chose "General Public" on a registration form.) It is added as a markup field in a webform.

Restricting access to user profile

Here is a helpful little snippet to prevent a user from accessing their own profile page, or changing their password. This is useful for cases where people are using some kind of guest account, or shared account.

Drupal multisite configuration

Drupal can do the following:


All these sites can use the same Drupal installation. The key is to point all of them at the same index.php file, which is in the root of the Drupal installation. This requires either a symbolic link to connect a site sub-directory to the installation directory, or Apache modification to do it. Once the request is received by Drupal, it will know which site to retrieve. /smoke and mirrors