Quicktips

The Views module has a little-talked about default view that provides a way to display all internal content that links to a particular page. Think of it as an internal "trackback" (or "pingback") that you often see on blog sites.

For example, when exposed as a block, the "backlinks" view displays a list of all the other content on your site that links to the current node. The page view can also be used - the view accepts a node ID as an argument to filter which backlinks are displayed.

When creating a sub-theme, if you want to add a new region to it, you must remember to redefine the default regions - or bad things will happen.

Here's an example: let's say you're creating a new theme called "squirrel" based on the 960 theme. Since the 960 theme uses Drupal's default regions if you just add your new region to the squirrel.info file, you'd find that all of your inherited (default) regions are now gone and your admin/build/block page is full of messages saying that all your blocks have been disabled.

When theming a Drupal site, I find that there are no sweeter words to hear from the client than "IE6 support is not necessary". Unfortunately, this phrase is far from commonplace. Currently, IE6 has about a 17% market share, so while it is shrinking, it is probably not small enough yet to ignore (but what a glorious day that will be).

I was recently was asked by a client to assist them in creating and displaying a block that would only appear on certain pages within the site. In their case, they wanted to only display the block on node pages - but only when the node was of a particular content type.

The Portable Network Graphics (PNG) format is a great way to display graphics on the web. It is meant to be a one-for-one replacement for the Graphics Interchange Format (GIF) but without all the proprietary craziness (for awhile there, UNISYS owned a patent that involved the GIF format). Unfortunately, its adoption has not been as fast or as complete as one would have hoped. The PNG format is lossless and generally compresses images better than GIF.

Whenever it's time for you to upgrade modules on your site, you should have a checklist of the steps involved. One step I've recently added to my checklist is to clear the site cache just prior to uploading the updated module files.

Drupal's core "Path" module is a great way to rename a URL on your Drupal site to something more user-friendly. Instead of telling a potential client that your "services" page is at www.example.com/node/324, you can just tell them to go to example.com/services.

The "Content Copy" module is a great little module that ships with CCK and provides a handy capability that not everyone is familiar with.

Most developers build a site on the local machine and then upload everything to the live server when they're ready. What happens when they want to add a new content type to the live server though?

With over 4,000 available modules, there's no way that anyone can know what each and every single module does. In my opinion, many developers often resort to writing custom modules too quickly without doing their due diligence in looking for an existing module to accomplish the same task.

When I'm working on a site that I think might require a custom module, there's a few steps I take before I break open my code editor (currently Espresso).

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.