This week I ran into a problem I’d never run into before with a view. I needed to specify some custom sorting that the Views UI simply doesn’t have options for. Luckily, views provides a hook for just this situation.

Quick tip on how I use Alfred to search Drupal API Documentation right from my desktop. Saves me tons of time and I love a solution that keeps my hands off of my mouse.

Back in February, I wrote a quick tutorial on how you can leverage Views, CCK and the Flickr module to create a photo gallery in Drupal. It is by far the most popular post on this humble site of mine (garnering about 36% of my traffic). Long story short, the Flickr module was updated (for the better) and the tutorial was outdated. The technique I described in the original tutorial was no longer correct. So, people following it (trusing that I knew what I was talking about) couldn’t replicate the results. This post is long overdue but I hope it helps clear things up on how to get the same results with the new Flickr module.

A quick post here. Often times I find myself building sites that have a blog and thus use the Comment module that ships with Drupal. That all works great. The problem is, later when I’m building out other content types, say Photo Galleries, I more often than not wish to disable comments on those node types. No problem, right? Just disable comments and get on with it. Well no – it’s not all right with me. I think comments should be disabled by default or at the very least, the Comments fieldset should be expanded by default so that you’re reminded to turn them off. Unfortunately, neither of these things are true on Drupal 6.

There’s an almost infinite number of ways to create a photo gallery with Drupal. I’ve tried many different approaches but never really been all that happy with the results. I’ve finally found a solution worth sharing/repeating. Here’s what we’ll be creating using Views, CCK and the Flickr module.

Last week a client of ours at CHROMATIC requested an addition to the default contact form that ships with Drupal. Essentially, they just wanted to add a required “Phone Number” text field to the form. Additionally, they wanted this value to be sent along with the email that the contact module sends. One solution would have been to ditch the contact.module and just whip up a new page using the WebForm module. The other solution is to override both the form/email using the following hooks respectively in our own module:

• hook_form_alter()
• hook_mail_alter()