Best practice for declaring functions within .tpl.php files?

Events happening in the community are now at Drupal community events on www.drupal.org.
bensheldon's picture

Is there a best practice (or is it just poor practice?) to declare a function within a .tpl.php. It seems like I should avoid declaring functions since these are templating files, but in some circumstances, it allows vastly simplified code---and I'm not sure where else I would declare a function within the concept of the themer pack.

I'm asking because I declared a function my Upload Attachment's List and discovered that there are some circumstances (like searching) where the function is being declared multiple times (which PHP obviously doesn't like). Removing the function would treble the size of the file and make maintaining it somewhat troublesome.

Should I pack the function within an .inc and use include_once() ? What other methods could (should?) I use? Your wisdom and experience is appreciated.

Comments

.

michelle's picture

Function declarations belong in template.php or in a module. They shouldn't be put in the .tpl files.

Michelle


See my Drupal articles and tutorials or come check out the Coulee Region

Never declare a function

merlinofchaos's picture

Never declare a function within a .tpl.php file. That is bad practice. You can declare functions in the accompying template.php or .module file.

Adding to template.php not very "pack"-able

bensheldon's picture

Thanks for the responses---I guess there isn't much I can do then if the only two options are adding code to template.php or creating a new module.

The reason I'm bummed out by these two solutions is that they aren't (in my mind) very "pack"-able. My impressions of the goals of a Theme pack was that it was a self-contained folder that I could drop into a theme directory and just work. Basically everything a module is, but strictly for presentation. If that's not the case, then I apologize for my expectations.

If I'm asking someone to edit their template.php, not only have I just lost the casual-user crowd, but I've also made for a maintenance headache.

Making this into a module seems a little overkill: if it's strictly presentation (and lightweight at that), it should probably live in the theme directory.

Any other ideas?

An option

dvessel's picture

One way to make it less intimidating would be to use the theme's .info file then extracting it from template.php.

example.info:

themepack[] = packname

"packname" would be the name of the folder containing the overrides within the theme folder. With that information, it can be extracted like so:

At the top of main template.php:

<?php
initialize_themepack
();

function
initialize_themepack() {
  global
$theme_info;

  if (isset(
$theme_info->info[themepack]) {
    foreach (
$theme_info->info[themepack] as $package) {
      if (
file_exists(path_to_theme() . '/'. $package . '/template.php') {
        include_once
path_to_theme() . '/'. $package . '/template.php';
      }
    }
  }
}
?>

As long as a file named "template.php" is within each packaged folder, it should be easy to work with.

I've done something similar to modularize each override grouped by the originating module but it used file_scan_directory() so it auto discovers then caches the result. I'm not sure I can recommend the approach for Drupal 6 though since I did this in Drupal 5 where .info didn't exist for themes. And it's tricky on detecting invalid caches.

Theme layer/API

Chris Charlton's picture

If you think it out more you can explain code via comments in a template.php file, or break it up as I think someone suggested here with includes and people can dig into the includes. If you think editing code is too much for anyone who would use your theme then you're trying to hard and maybe should just release something simpler. I just woke up so please don't take my comment as mean, but I think either you go forward or pull back.

Themes can be programmed with custom administration settings. Take a look at Garland and a couple others who use the color module or have theme configuration screens to come up with features that would not require code at all.

Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant

I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us

Well, you can't include

merlinofchaos's picture

Well, you can't include something that will 'just work' because only .tpl.php files are auto discovered.

That said, you can include mypackage/template.php and include instructions to add "require_once mypackage/template.php" into their theme.

That said, the way Drupal is set up now, .modules can do a LOT to be mini themes now, and I think that's a better way to go. Modules are going to give you a lot more flexibility and control, plus, anything you put in a module can still be overridden in the theme without having to edit the files you give them.

This is what advanced forum is doing in Drupal 6; it's like adding a bit of theme layer in a module.

Aggregate template files?

Setzler's picture

Why can't template.php files be named nnnn-template.php? Besides, "template.php" was a bad name for that file... Would have preferred nnnn-functions.php.

Is it possible to write a module that intercepts the tpl discovery?

I love drupal site

shaffy's picture

I love drupal site

Themer Pack Working Group

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: