Blog

I put together a small module for a recent project that extends Webform to include a "roster" form. Basically, you can assign Webform B to be the roster form for Webform A. When a user completes Webform A they're sent a link to complete Webform B. This link can be used an infinite number of times, so the original user could fill out Webform B immediately, or send the link to a dozen others (which is what my needs are). All of the Webform B submissions are tied to the original Webform A's submission, and show up when viewing that original submission.

I can't stand the over-use of contrib modules when they just aren't necessary. When a visitor loads your Drupal front page, all of your modules are opened and read by the server whether they affect the front page or not. PHP searches files for hooks that need to be fired, a huge number of database requests are made that don't necessarily have a purpose, and on the list goes. Why use modules that perform tasks already available to you such as including a JS library in your theme's folder, firing a trigger/action when a user logs in, or building your own custom content type?

The function behind the $node object is node_load(). This brings the $node object into play within your node.tpl.php template file and gives you the ability to display any variables from the node. Drupal handles everything behind the scenes -- access permissions, attached taxonomy, attached files, meta information, and more -- and hands you the gift wrapped object. In addition to the core variables, the node object also includes any added variables, such as CCK fields. 

I stumbled upon Mail Carbon the other day, a great little open source app @ sourceforge (http://mailcarbon.calfater.com/) that allows you to specify 2 IMAP servers & the user's account information, which then transfers all of the email from the old to the new, maintaining hierarchy (folders) and all of the good stuff that we get out of IMAP.