CCK individual field themeing

Tue, Feb 9, 2010 by Afraaz

CCK is a great module for allowing use to create custom content types without having to write a node module. Out of the box CCK provides everything a user would want. But there are times where I need to do some custom queries or add a custom theme function to get things just right. So here's something I like to do to keep things well and organized.

The best way to do this would be to copy the content-field.tpl.php from the CCK theme directory into your own theme directory. This will target ALL fields, but you'd like to modify onlt that one text field in that one content type. Well, you'd start off again by moving the content-field.tpl.php to your theme directory, and then create a copy of this file with the following schema:


content-field-FIELD_NAME-NODE_TYPE.tpl.php

If you'd like to modify a field that spans across multiple content types, you could use the following naming convention:


content-field-FIELD_NAME.tpl.php

I usually have a module for each custom content type if there is to be extra functionality to be implemented. So what I like to do is implement the following in my module:


function hook_theme_registry_alter($themes) {
  $module_path = MODULE_PATH
  $themes['content_field']['theme paths'][] = $module_path;
}

The above code will suggest different paths of where template files may reside for the given theme function. From here, you can follow the same steps of copying content-field.tpl.php to your path and you'll be able to override the theme of the CCK field. You probably could even add preprocess functions if you wanted to do preprocess the field.

This sort of implementation allows us to override the output of a single field. This also makes it so that we're not dependent on the theme and that our content type fields will be themed exactly the way we need it no matter which theme we use. There are probably pros and cons about this implementation, so feel free to share your ideas or thoughts.

The interweb my ~ away from ~

ize posted on April 18, 2010 6:54 pm

@Afraaz: Very helpful post, thanks!

@whatdoesitwant: I see your concern, and generally agree with you. But sometimes module functionality is intertwined with things that _could_ be handled at the theme level as well... for example, a module might require a field to have a specific css id in order for some AJAX magic to work. In those cases, the approach here looks good to me. But if there's a better way to handle those situations I'd be interested.

Is it possible to have the best of both worlds, and preserve themers' ability to (further) customize the field's theme? Would the module path have to be inserted _before_ the theme path in _$themes['content_field']['theme paths'] for that to work? Or would it actually be better to just use preprocess functions?

Af posted on February 11, 2010 12:08 am

Heyya,

I'm against killing kittens, so maybe I'll stop, lol. On a serious note, I do this so I don't need to rely on the theme layer for my field to be themed the way I want it to be. Let's say I wanted to reuse this module and content type on a different project, this would allow it to be themed the same way.

Reusing content types and modules is something I like to do to cut down on development time. You will still be able to override the field theme in the theme layer, so it's not too much of an issue for themers.

When developing it's integral to the project you keep ALL communication lines open, therefore I hardly ever run into issues with my designers.

Thanks for the question. And hopefully, you'll forgive me for the hypothetical kittens.

whatdoesitwant posted on February 10, 2010 10:48 pm

I read your tweet. Is what you're trying to do here to take the themeing end decision back from the theme layer into the module? Because that's, like, killing FIVE kittens! Can I still somehow override? How difficult would it be to find out what's happening for an unsuspecting themer? These two questions are very important if you want to end up with something sustainable.
You obviously know something about design. Why go this route?

(Why does mollom always think I'm spamming. grrrr.)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <h2>
  • Lines and paragraphs break automatically.

More information about formatting options