cailin's blog

my favorite picks for reading to kids aged 0-2 years. check out related posts on best baby gadgets and best baby and toddler toys. if you're curious about the inspiration behind the list, visit ava's blog.

my favorite picks for keeping the little one entertained. check out related posts on best baby gadgets and best baby and toddler books. if you're curious about the inspiration behind the list, visit ava's blog.

a quick list of the most useful gadgets for keeping the little one clean, fed, and comfortable. for entertainment and education, check out related posts on best baby and toddler toys and best baby and toddler books. if you're curious about the inspiration behind the list, visit ava's blog.

the blessing and curse of cck is the ability to quickly create very complex node types within drupal. it doesn't take very long before the input form for a complex node type has become unmanageably long, requiring your user to do a lot of scrolling to get to the bottom of the form. the obvious solution is to break your form into multiple pages, but there is no easy way to do this. there do exist two proposed solutions to this, the cck wizard module and a drupal handbook entry. however, the well-intentioned cck wizard module doesn't seem to work, and the example code in the drupal handbook becomes tedious to repeat for each content type. to fill the void, i bring you cck witch

cck witch is based on the same premise as the handbook entry : the most natural way to divide a cck form into pages is to use field groups. from there, however, cck witch diverges, taking a relatively lazy, yet effective approach to the problem of multi page forms: on every page we render the entire form, but then simply hide the fields and errors that do not belong to the current step. it also offers an additional feature : when the form is complete and the node is rendered, an individual edit link is provided for each step - allowing the user to update the information only for a particular page in the form, without having to step through the entire wizard again.

if you've now read enough to be curious to see the goods, then please, be my guest and skip straight to the live demo.

if your career as a developer has included a stay in the j2ee world, then when you arrived at drupal one of your initial questions was "where's the log file?". eventually, someone told you about the watchdog table. you decided to try that for about five minutes, and then were reduced to using a combination of <pre> and print_r to scrawl debug data across your web browser.

when you tired of that, you learned a little php, did a little web research and discovered the PEAR log package and debug_backtrace(). the former is comfortably reminiscent of good old log4j and the latter finally gave you the stacktrace you'd been yearning for. still, separately, neither gave you quite what you were looking for : a log file in which every entry includes the filename and line number from which the log message originated. put them together though, and you've got log4drupal

log4drupal is a simple api that writes messages to a log file. each message is tagged with a particular log priority level (debug, info, warn, error or emergency) and you may also set the overall log threshold for your system. only messages with a priority level above your system threshold are actually printed to your log file. the system threshold may changed at any time, using the log4drupal administrative interface. you may also specify whether or not a full stack trace is included with every message. by default, a stack trace is included for messages with a priority of error and above. the administrative options are illustrated below :

don't get me wrong, i'm a happy customer of the drupal hovertip module. everything worked out of the box, and i've enjoyed using it to cram even more pictures into my website. however, the included default css leaves a little to be desired for the following reasons :

1. it's too specific. it assigns a very particular look and feel to your tooltips, complete with background colors, fixed widths and font sizes. sure, in theory, you can override all that in your theme css. but if css specificity is not your thing, you're going to be tearing your hair out trying to figure how to do it.
2. the ui element chosen to indicate "hover here" is non-standard. the "hover here" directive is admittedly fairly new, but the emerging standard seems to be the dashed-underline (certainly not the italic font used in the drupal hovertip module).
3. the clicktip css does not work on ie6. the link to close the clicktip has mysteriously gone missing.

you can download a more generic, flexible version of the necessary hovertip module css that solves all these issues here. here are some examples of how to use it.

out of the box, the views module allows you to specify access to the view according to user role. this is a critical feature, but sometimes it's not enough. for example, sometimes you may want the view access to depend on the arguments to the view.

specifically, let's suppose that we have implemented facebook-style threaded mail, and we want to use a view to display all the messages in a thread. the thread id is an argument passed to the view. we only wish to allow the view to be accessed by one of the authors of the thread, or users with the 'administer messages' permission.

here's a three step approach to resolving this dilemna :

previously, we discussed implementing all of the node hooks for CCK content types except hook_access. unfortunately, there is no access op for hook_nodeapi. adding this to drupal core is the topic of much discussion on drupal.org. so far a resolution to the issue has failed to be included in drupal 5 and drupal 6, and is now on deck for consideration in drupal 7.

a common path followed by advanced drupal developers using cck is the following

1. create a content type using cck
2. create a supporting custom module to handle advanced customizations. typically, the module is given the same name as the content type

in this custom module, developers then attempt to implement standard drupal hooks like hook_access and hook_submit. much confusion then arises as to why the drupal hook is not firing for the cck content type.
the reason is the following. hook_access, hook_insert, hook_submit, hook_update and hook_view only fire for the module that owns the content type. for cck content types, the module that owns the content type is content (e.g. cck) not your supporting custom module. therefore, drupal leaves your supporting custom module totally out of the loop!

the trip they said would never happen . . . finally happened. we've only been trying to go to the eastern sierras for two years now, and we've called it off so many times that i can't even remember all the excuses. way back in the say it got called off due to good surf. shortly after ava arrived it got canceled by ava's pediatrician who seemed to think it was a bad idea to take a 6 week old sea-level-dwelling-newborn up to 11,000+ feet. the most recent cancellation was last weekend, due to an unseasonably early snowstorm.

the drupal actions module is one of those useful and under-documented drupal modules out there. this blog is not meant to serve as complete documentation for this module, but will provide some helpful hints to get you started.

generally speaking, vim is a pretty smart text editor. if you put the following in your .vimrc file

then it will color highlight your file appropriately. it chooses the appropriate color highlighting by looking at the file suffix (e.g. .java, .c).

unfortunately, the drupal .module and .inc files fool vim, because these are not standard php extensions.

google analytics provides for arbitrary javascript event tracking. anywhere in your page that you can put an onClick or an onMouseOver or any other event you please, you can also name that event and track it in google analytics. this is particularly handy for tracking hits to downloadable content (for example pdf files).

Drupal provides two methods for adding structured data to a node.

The first is the out-of-the-box Taxonomy module. Taxonomy allows you to associate a vocabulary with a content type. When creating or editing the node, you are invited to choose a value for the vocabulary from its associated list of terms. In essence, you are associating a structured field with your node. The name of the field is the name of the vocabulary and the value is the selected term.