Ever downloaded a module and noticed several obvious bugs? Often, you can look in the issue queue for a module and find fixes, code patches, and help with these problems. For certain modules, the maintainer of the code may not respond - he or she may no longer be developing with Drupal, may have changed his or her email address, or any number of other factors.

If you are a Drupal module developer, then the title of this Quicktip might be enough for a lightbulb to suddenly appear above your head.

Whenever you need to write a custom module that involves redirection using the drupal_goto() function, things can always get tricky - especially if there are other forces at work. One such force might be the "destination" variable that sometimes gets passed around in the URL querystring when the user is attempting to access content that requires authentication.

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.

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.

Need to write a module that implements a form that needs some AHAH magic? Then use the awesome AHAH Helper module.

The brainiacs over at Lullabot recently unveiled api.lullabot.com, their version of Drupal.org's API documentation site. While on the outset, it seems similar, there are some nice features of the Lullabot site that make it very worthwhile to use.

First and foremost, in addition to documentation for Drupal core, they also added the documentation for a large number of popular Drupal modules, including Views, CCK, and Ubercart.

One of the attributes that you can set for any form element using Drupal's FormAPI is "#disabled". This effectively disables the form element - in most browsers, the user actually sees the element "greyed out" and is unable to set focus on the element.

Sometimes you need to set some global variables in Drupal that aren't used by just a single module, but rather a set of modules. You can take advantage of the $conf array in your site's settings.php file to set these variables that your various modules can then access them using the "variable_get()" method.

For example, I have a client that pulls in some data from an external SQL Server database to their Drupal site. Data is pulled in by a variety of custom modules and they wanted to have a single, secure place to set the database connection information.