Group 42

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!

The addition of preprocessor functions to Drupal 6 makes customizing template variables straightforward and clean (bravo to everyone who made this happen!). Have you ever wondered where the variables come from? It's actually helpful knowing, even if you're a themer with basic PHP knowledge.

Some reasons why:

• Seeing how the the variable is created allows you to make an informed decision on the best way of changing it. e.g., Modifying the theme function vs overriding the value.
• In the case of a module, knowing the logic behind how a variable is created can tell you whether or not a Drupal function should be used to add the information to the theming layer.
  e.g. $head / drupal_get_html_head() / drupal_set_html_head()
• Often a theme function is used to generate the variable. Copying the technique can simplify your code.
• Knowing the logic behind how a variable is created can aid troubleshooting.

In Drupal 6 the variable creation logic lives in the /includes/theme.inc file. The functions of note, located at the bottom of the file, are:

Need to know absolutely, positively, and without-a-doubt what theming variables are available to your template? Here's a trick for total visibility.

In my previous post, Take Control of Your PHPTemplate Variables, I described the _phptemplate_variables function in template.php. It's passed a parameter named $vars which is an associative array of all the variables that will be created in the template . . . which is exactly what we're looking for!

Since _phptemplate_variables allows us to create theme variables, we have a simple way to get the $vars data into the template where we can look at it. Just put the following code in your template.php file:

function _phptemplate_variables($hook, $vars) {
  return array('vars_data' => $vars);
}

And the following code in your template file:

For your templating pleasure Drupal's PHPTemplate engine makes available a cast of variables, including such favourites as $title, $content, and $node. Modules also contribute: CCK adds CCK specific template variables as well as fields to the node object, and the comments module adds an entry to the $links variable. But what happens when something isn't formatted the way you or your customer wants, or you have a project specific variable you want to add?

Introducing the _phptemplate_variables function!

The _phptemplate_variables function lives in your theme's template.php file and is called by the PHPTemplate engine after the various modules have done their thing, and before PHPTemplate actually renders your node into HTML. _phptemplate_variables provides a single, common location to all .tpl.php files for adding or changing variables.