Posted by: 
Dominique De Cooman

In drupal 7 the recommended method to render output is by using the render api. So no more calling theme(...) directly. Here is a simple example based on the example from the examples module.


function render_something() {
$render_array = array(
'child' => array(
t('This is some text that should be put together'),
t('This is some more text that we need'),

Posted by: 
Dominique De Cooman

If you want to render only one field of your entities you can in drupal 7. Here in the example we have an entity called model which contains an image field.

To render the field you have to specify to the field_attach_view function which entity type, the entity and the view mode you want to use. The function returns a renderable array.

Pretty form theming module

Creating uniformity between all your browsers.

Gettting the labels for a cck field

Dont print labels hardcoded in your templates, they are configurable by interface.

Posted by: 
Dominique De Cooman

How to add another formatter to a cck field? A cck formatter is basically a theming function where the value of field is ran through. Formatters are available at "admin/content/node-type/[your node type]/display" in the cck interface.

What it does

With this module you can theme your nodes by interface in a easy user friendly way (unlike panels, which can do pretty much what ds can but with a million clicks more).
The display suite is collection of modules all sharing the same api, the modules that implement the api are:

For example if you want nodes with cck fields styled and pull views according to the defined buildmode you need to install display suite, node displays and node displays contributions.

How it works

It divides the $content variable in your node tpl into regions like left-right-header-footer etc. Every CCK field on the node can be dragged into a region using the interface. Other fields like the fivestar widget forexample can be dragged too using the nd_contrib module.

You can have your own modules exposing their widgets to ds. It saves lots of theming work. Often you have a multiple lists of the same node types on a site but they are themed differently. With ds you dont have to touch your tpl files. Just created a new display and apply it to your view, that's right views support is present.

It is an alternative way of theming. When new fields are needed they are exposed to the display suite using the interface by creating new fields (even with php code). I would not recommend using php in interface defined fields because it is more difficult to maintain. In stead I would recommend to implement hook_ds_fields() and maintain your fields in code.

For example you want the "share this button" as a field, so you be able to control it with ds. (full hook documentation

 * Implementation of hook_ds_fields().
function your_module_ds_fields($type_name$build_mode$extra) {
$fields['sharethis'] = array(
'title' => t('ShareThis'),
'properties' => array(
'formatters' => array(
'your_module_final_sharethis' => t('Default')
  return array(
'nd' => $fields);

your_module_final_sharethis() {
$object $field['object'];
  if (
is_array($object->links['sharethis_link'])) {

When you need new formatters just implement the cck api hook_field_formatter_info() to expose new formatters to ds.

Look here on how to add a custom formatter

The whole approach is a very nice process for the designer aswell as for the developer. The developer doesnt have to worry about the correct html output and doesnt need to move around html in the tpl files anymore. the designer can just concentrate on his css and doesnt need the developer to change something in the tpl.

Also flexibilty is enormous, with just some clicks, the theming of a node can be changed very easy, maybe some css is required but again no messing around in the tpl. So no more panic if the client wants that image left instead of right, a few clicks and the problem is solved. It is so easy to use that you can allow clients to use it without having to worry they ll break the site.


It does generate a lot of divs and some themers have complained about it being difficult to maintain overview.The best way to explain to themers is that they have to see the output of the display suite as a mini page tpl. Analogic to the page tpl which has regions that collapse whenthey are empty and take a percentages of the space when they contain blocks, the $content has node-regions which will show up when fields are dragged into it and colapse when they are empty. It is true that the first project has a learning curve for both themer and developer.

Also some SEO people have complained about the "excess" div problem not being SEO friendly. Personaly I feel it doesnt add up to the advantages it brings to your site. Installing this module will save you some much time in the long term that you be able to use that time to write great content which is a 1000 times more effective to make your site show up in search results than eliminating a couple of divs and sacrificing the flexiblity of changing your displays.


It has an extensive api with hooks and alters for allmost anything that happens.


Blog topic: 

This module has the potential to fill the form theming gap. For now it is still in alpha but it has potential.
It uses jquery to arrange your form elements. Takes into account fieldset (but not the field in the fieldsets).
It does not integrate with the multistep module.

Posted by: 
Dominique De Cooman

A solution is suggested on
In case it doesn't work, I explain a different method in this post that worked for me.

Posted by: 
Dominique De Cooman

This article explains how to switch your theme. In our example we will switch the theme if one of the fields of our node has a certain value.

Posted by: 
Dominique De Cooman

You have a node type containing an image field. You want to construct a feed containing the image (and node title) but the image needs to be resized to a format you don't use on the site.
I'll explain how to do it.


Subscribe to theming