More often than I'd like to admit, I run into the same little issue that usually takes me more than a couple of minutes to figure out. In this specific case, the small issue that I'm talking about is map views that I create not showing all the markers I think they should.
This is going to be a really quick QuickTip today - if you've ever added a generic text field to a CCK content type to contain a phone number - stop it.
Image Resize Filter is an fantastic tool for giving content administrators the ability to place and resize images within rich-text editor-enabled fields. The genius behind this module is that it is actually a Drupal input filter that resizes images on the fly based on what the user does in the rich-text editor.
If you use CCK's Node Reference field often, then this tip is for you.
Occasionally I run into the situation when I start adding a new node that contains a Node Reference field only to get half-way through before realizing that the node I want to reference doesn't exist yet. At that point I have to stop what I'm doing, open a new browser window, create the node I want to reference, then reload the original node's "add" form. What a hassle.
If your client is being very picky about the titles of certain pages, especially views, you may find yourself needing to write some code to set the title at the theme level. This is normally fine, since Drupal 6 has some great hooks, like hook_preprocess_page() and its cousins for blocks, nodes, and user profiles.
There have been several times where I've had to write a custom module that enables the site admin to make some major changes to their site. With changes like these, I want the site admin to be super-duper sure they know what they're doing, so while sometimes I use Drupal's built-in Confirm Form function, I sometimes decide to take a less-intrusive approach.
One of the first things I look at when a client asks me "why is my web site so slow" is the admin/build/modules page (actually, the first thing I look at is the client's internet connection). It's very rare that I don't find more than a couple of modules that are enabled for absolutely no reason - sucking down precious server resources.
Here's a few that I find most often - and are usually no-brainers to disable:
If you've ever done any Drupal module development, then you've probably run across the node_save() function. This little beauty is the equivalent of the "submit" button on a node form. If you know anything about module development, you know that any module can tap into the "node save" process via hook_nodeapi(). By manually creating a node in code an saving it to the database with node_save(), you allow all the other modules on your site the opportunity to add their magic to your new node.
We have a client for whom we're helping set up a system to sell access to multimedia content through their web site. Virtually all of the media will be streaming, so the goal is to simply sell access to particular nodes on the site where they'll keep the protected content.
Ubercart has a handy module for taking care of all of this. It's called the UC Node Access module.
The Calendar module is one of those modules that seems like it should be dead-simple to use, but often overwhelms site admins once they get their first look at it (actually, it is pretty easy to use).
The Calendar module is basically just a great big Views add-on. It requires the Date module as well, but all of its user interface is done via Views.
Often we have clients for whom we are developing a theme who request that they have several different block styles to choose from. Sometimes each style is completely different (colors, borders, images) while other times it is something as subtle as a different header icon.
Anytime you write a Drupal module, you should always have the Coder module installed and enabled to check your code when you think you're done.
I'm tempted to end this QuickTip here, as that's all you really need to know.
I'm currently involved in a project that has a number of related content types. Part of the initial phase of the project was to define the information architecture (IA) for all the types so that we can squeeze all the functionality out of them that we can once we implement everything in Drupal.
If you've used version 2 of the Calendar module, then you've probably been quite impressed with its fantastic Views 2 integration. If you're like me, then when you start using a new module, you often just enable all the little modules that comes along with it. In the Calendar module's case, this includes not only the main Calendar module, but also the "Calendar iCal" and "Calendar Popup" modules.
If you've been following along with recent Drupal news, then you've probably heard about the 960 Grid System for laying out web pages. The associated Drupal starter theme, NineSixty was one of the stars of the recent Design 4 Drupal camp in Boston and is making some headway into possibly finding its way into Drupal 7 core.
If you want to get kick-started on learning about 960, here are some great resources: