Group 42

An example, like a picture, is worth 1000 words. Until recently Drupal programming examples existed but were spread among documentation pages, blog posts, and the Drupal CVS repository; some searching required. That changed in late 2009 with the introduction of the Examples for Developers module. Its purpose: "to provide high-quality, well-documented API examples for a broad range of Drupal core functionality". Now you can find high-quality, working Drupal 6 and 7 code examples in one place, many with SimpleTests.

The Examples for Developers Module, or simply Examples Module, is actually a collection of modules. Each sub-module contains a single, specific example of how to use an API or implement a feature. At the time of writing there are 17 examples:

Drupal's scripting abilities just keep getting better and better. Since publishing my Drupal Command Line Script Template last year I've moved exclusively to the Drush php-script (scr) command. The script template article still gets a lot of page views - perhaps because with all the functionality in Drush it's easy to miss the scripting feature - so posting an update seems like a good idea.

Drush Scripting Advantages/Disadvantages

The advantages of using Drush over using my original template are:

• Drush takes care of creating the Drupal environment for the script to run in, which is the only function the template served. Using Drush factors out the environment common code, eliminating redundant code in individual scripts.
• Drush makes it easy to place the script files in a directory outside of the Drupal website home directory. Placing script files outside the website home directory eliminates a whole range of security issues.
• The Drush code that creates the Drupal environment is reviewed by the community, making it far more robust than something a single person could create or maintain on their own.
• When the code required to create the Drupal environment changes you don't need to update individual templates, just Drush.

When image-sets are discussed it's usually in the context of a full featured photo gallery, but there's another common use: including a set of images with the content of a node. For example, product images with a product node or a "mini" photo album with an article. The CCK ImageField combined with a jQuery module like Thickbox makes adding image-sets to nodes easy. Here's how.

Overview

This "recipe" describes how to add a gallery style photo-set to a node. This photo-set stands apart from the node content as a set of thumbnails which can be clicked on to display the full-size version. The Thickbox slide-show feature is also implemented so viewers are able to step through the full-size version of the pictures without exiting the viewer. Although Thickbox is used, this technique should be easily adoptable to different plug-ins.

An example of the technique can be seen here: Finding the Blue Whale

Anyone who's tried to explain Drupal's content feature-set to the uninitiated appreciates the amount of territory that needs covering as well as the challenges inherent in presentation depth and order. J. Ayen Green takes up the challenge in his book, Drupal 6 Content Administration, published by Packt Publishing. Packt graciously provided me a copy for review.

The stated purpose of Drupal 6 Content Administration is "a quick-start guide that best serves Drupal Content Editors." Green is serious about the audience and serious about the content focus. The discussion and examples are firmly rooted on content and live in the user interface, using language targeted to the audience; except for the appendix, there are no digressions into unrelated topics like site administration, SEO, or account management.

The book's content falls into three broad categories: authoring/formatting content, methods for displaying content, and managing content. Each subject has a short introduction and explanation, and almost all include an example of something that can be implemented with step-by-step instructions for doing so. Green has made an interesting decision, the step-by-step instructions assume the Drupal site has already been configured and he does not digress into a discussion on configuring the modules required for the example.

Drupal RSS functionality is spread out, and so is information on it. After first accumulating mental notes, which turned into a collection of written notes and code snippets, I realized there's a lot to be said on the topic. A single overview covering all things RSS seemed like a useful idea. This is a starting point covering many things RSS. I invite you to leave a comment if you have anything to add, a great reference or blog post, or if I've gotten something wrong.

"Out of the box" RSS

• RSS is configured and controlled at Administration > Content management > RSS Publishing
  
  
• The default RSS URL is rss.xml (e.g. www.example.com/rss.xml)
• The default RSS feed selects content using the same selection criteria as the /node path ("/node" is the default front page setting). It contains the content of any node that's both "Published" and "Promoted to front page".
  
  
  
  The exact content and number of nodes is determined by the RSS settings.
• There is no provision to theme a node's RSS output in the PHPTemplate theme engine. Your node.tpl.php file is ignored when the feed content is rendered.
• Because of the above point, double check the RSS feed output of any feed containing nodes you've created or modified with CCK.
• Every taxonomy term automatically gets a feed (whether you want it or not)
• The is no provision in the Drupal base installation (core) to publish comments in a RSS feed. A contributed module (RSS Comments or Views) is required. More on this later on.
• The RSS feed will only be published on the front page. More on this later.

Putting location data on maps, especially dynamically, used to be a dream. No longer. Thanks to open standards, APIs, Internet based map web services, and many hours of work in the Open Source community, a new wave of options are available for putting location based data on maps. And Drupal is surfing this wave!

In a presentation to the Vancouver League of Drupaliers (Vancouver's Drupal user group), Affinity Bridge founder Mack Hardy gave an overview of locative and geo-related modules in Drupal 6. Here is a video of that presentation.

Geo-Location in Drupal 6

This video can also be viewed directly at: Geo-Location in Drupal 6 by Mack Hardy

The LinksDB module provides a nice "it just works" way for implementing a classic Links page. The standout feature is its hierarchical display of the URLs. Even after Views and CCK arrived, the hierarchical display was worth staying with the module. Sadly, with a site to upgrade and no Drupal 6 version of LinksDB in sight, it was time to convert.

This post is part 2 of 2 of how I migrated the CIPS Vancouver Security SIG Links Directory page from LinksDB to CCK/Views. In part 1, Migrating LinksDB Module Data to CCK, I covered migrating LinksDB data into Drupal nodes and taxonomy. In this post I cover creating the URL Links directory page in Views.

Even if you're not interested in LinksDB, this post provides an example of theming Views to display a hierarchical list using taxonomy to define the hierarchy. This same technique was used to render my Drupal Notes page.

Here are before and after screen shots of the SecSIG Links Directory page:

LinksDB Module Page

Views Replacement of LinksDB Module Page

View Definition

The View definition is un-extraordinary. Here is a snapshot of its edit page, an export of it is included at end of this article.

The LinksDB module provides a nice "it just works" way for implementing a classic Links or Resources page. The standout feature is its hierarchical display of the URLs. Even after Views and CCK arrived, the hierarchical display was worth staying with the module. Sadly, with a site to upgrade and no Drupal 6 version of LinksDB in sight, it was time to convert.

This post is part 1 of 2 of how I migrated the CIPS Vancouver Security SIG Links Directory page from LinksDB to CCK/Views. It covers migrating LinksDB data into Drupal nodes. Creating a hierarchical display with Views is covered in part 2.

Creating a CCK node to replace the LinksDB URL entry is trivial. The two areas requiring work are migrating the data in the LinksDB database tables to standard Drupal data objects (CCK and Taxonomy), and creating a hierarchical listing of the URLs in Views.

Even if you're not interested in LinksDB, this post provides an example of programmatically importing data into Drupal using a command line script.

LinksDB also provides some user-facing tools for suggesting links, counting outgoing link clicks, and flagging dead links. Due to spam the suggestion tool was turned off; users have been savvy enough to use the contact form for suggesting links. The tool for flagging dead links didn't prove that useful and the tool for counting outgoing links was never used. These tools were therefore not re-created.

The CCK Node

The 4 fields defining a link entry are: name, URL, description, and category. Here's how I defined them in CCK.

Note: Drush is now a better option for running Drupal scripts. Please see this article for more information: Drupal Command Line Scripts with Drush.

There are development tasks better suited to running in a command-line script than in the Drupal web interface. The two most notable in my experience are code fragment testing, especially when exploring how an API works, and data import/export. Happily, this kind of scripting is possible with Drupal.

The PHP code shown below, created from examples seen in Planet Drupal posts, and later in the drush module, is serving me well as a command-line script template. It works in both Drupal 5 and 6.

Script Template

Usage Notes

Note: It's worth reading through the comments on this post, this technique isn't as useful as it first appears - Dale, Feb 18/09

Browser specific CSS is sometimes unavoidable. The common method for handling it is conditional stylesheet includes. The SitePoint article, How to Use Conditional Comments for Better CSS, which credits Paul Hammond's post, Conditional classnames, discusses a technique for doing browser specific CSS without different stylesheets. The ability to consolidate related CSS instead spreading it across multiple stylesheets seems like a great idea.

This method takes on further elegance with Drupal because the ugly conditional statements are not required to apply the classname to the body tag. The browser specific classname can be generated in the template code.

Although I'd stashed the idea away in my "cool file" I hadn't considered writing about it until I'd read Squiggy Rubio's article, A Review of Drupal 6 Starter Themes. Co-maintainer of the Basic Theme, Steve Krueger, commented that Basic uses this technique, describing it as "one 'smaller' feature that wasn’t mentioned that I think deserves its 15 minutes." Squiggy Rubio agreed, and so do I!