Quicktips

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

Drupal's Batch API is a great tool for module developers to leverage when an extended task needs to be performed. The Batch API is used during Drupal's own core installation and by modules like Node Import.

Unfortunately, sometimes the default settings of PHP's mod_security extension can interfere with some implementations of Batch API.

I've imported my fair share of content using the Node Import module and one thing I always watch out for is empty data. Spreadsheet with blank columns that need to be imported always seem to cause problems.

In many technical Drupal how-to articles, the author will refer to "Drupal User 1" or "the first Drupal user" or "UID 1" - in all cases, the author is referring to the initial user that was created when the site was first set up.

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.

The "disabled" attribute for form fields is a great little user interface helper that you can use to help protect data from accidental changes. It locks down an HTML input form element so that it can be viewed, but not be changed. This is handy when displaying a form to a user where you need an extra layer of protection for the data.

What happens when the user goes to submit a form with disabled elements? The value of the disabled elements are not passed back to the browser - this can quickly turn into a data validation and/or submission issue.

Views 2 for Drupal 6 was quite the upgrade for those of us who were comfortable with the original version. It was pretty much a stellar upgrade in all aspects, but it requires a bit of knowledge and commitment to reach the point where you feel comfortable and confident with it.

In my opinion, one aspect of Views 2 that doesn't get the attention it deserves is the fantastic template-based way that it handles theming. You can theme virtually any aspect of a views result by overriding any number of template file.

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.

If this Quicktip saves one person as much time as it should have saved me, then consider this post a success.

When setting up your Ubercart-powered site, be sure to set the input formats for the email templates correctly - otherwise the super-pretty default HTML templates that get are supposed to be sent out will instead be sent as plain, unformatted, difficult-to-read text.

Adding form fields to a Drupal form dynamically is not the most straight-forward task. You'll see this occasionally on a Drupal form (poll module jumps to mind) when there is an "add another" button that (seemingly) simply adds another set of input elements to the form. The big sticking point in setting this functionality up is doing it in a way that keeps FormAPI's security intact. Fortunately, there's some tips to get you mentally started.

When writing a module from scratch (or trying to deconstruct one to figure out how it works), it might save you some time to be aware of "wildcard loader arguments" when using hook_menu(). These wildcard arguments are automatically linked with "_load()" functions that allow the module developer to load data into the argument anytime the menu item is called.

Here's a quick example of what I'm talking about. Look at this snippet from the Quicktabs module's quicktabs_menu() function:

We all know imagecache is a great module to grab images of any size that are in your site's files/ directory, but sometimes it's hard to get every image to be the right size without black borders on the sides or top. The trick is to know the proper "order of operations".

Here's a fast recipe for square thumbnails that will work with landscape or portrait picture orientations:
Scale - width: 85, height: , upscale: No
Crop - width: 85, height: 85, xoffset: , yoffset: top
Scale And Crop - width: 25, height: 25

One of the things I really love about Drupal 6 is its "Status Report" page, located at "admin/reports/status" (or "Admin|Reports|Status report" if you're drilling down through the menu system). This is my first stop whenever I think something wonky is going on with a site.

When writing custom modules, few functions are as useful as filter_xss(). In a nutshell, this function protects your web site from both malicious HTML and unwanted tags.

The function takes some text and, in effect, "cleans" it based on some very simple rules. First and foremost, it makes sure any HTML elements, tags, and attributes are well-formed. It also removes any non-standard characters and constructs that can trick browsers. Finally, it can remove any HTML tags depending on an argument passed to the function.