Quicktips

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:

The Block Class module allows you to add CSS class names to any block on your site via the block's configuration page. This is extremely useful if you want to make just one of your blocks look a little bit different than the others.

For example, let's say you want the header of one of your blocks to be red. Here's how you'd do it:

1. Download and enable the Block Class module
2. Add the magic snippet to your block.tpl.php file (see the Block Class's readme.txt file for details)

Does your site send out HTML-based emails? If so, then you should be aware of the Email Standards Project web site. This site provides a plethora of information on how to ensure your HTML-based emails are rendered properly on a maximum number of email clients.

The site provides a super-simple email client scorecard on the homepage (surprise - Outlook is rated "poor") as well as an acid test for email clients.

One of the first things I do when creating a new site is to set the Administrative Theme (admin/settings/admin) to Garland. Two of my main reasons for doing this are:

• Customer-facing themes are often "heavier" (more images, more CSS, more complex layouts) than core Drupal themes.
• Garland is a fluid-width theme. Having this flexibility is key in the admin area especially when the main theme is fixed-width.

If you build Views with lots of display attachments, you've no doubt run across the hurdle of re-ordering the attachments. There's no drag-and-drop method of doing so - often developers are forced to go into each attachment changing the attachment position several times in order to wrangle the attachments to the desired order.

One way of getting around this is to export the view, bring the export text into a text editor, and manually move the attachments to the desired order simply by cutting and pasting the attachment code and then re-importing the view.

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).