display suite

Configuring fields with Display Suite for Drupal 7

The 7.x-1.1 release of Display Suite comes with a couple of new exciting features:

  • Fivestar
  • More hooks and better views extendibility
  • Ability to hide the page title on full node view
  • Custom field templates via the UI

The last feature is better known as the cure for divitis feature for the field system. Or you can also call it semantic fields. The possibilities to theme entities through the Field UI have now become endless. I'll explain those changes with code and screenshots, which should convince you how powerfull and easy Display Suite can be for your website. And best of all, this is all exportable!

Display Suite Extras

The field templates feature is located in the Display suite extras module, so it isn't enabled by default. But once configured to run, all fields, in every entity/bundle/view mode, on the "Manage display" screens get the ability to change following properties of their output:

  • Label: a custom label, wrapper and classes
  • Styles: extra styles on the outer wrapper (except reset or expert)
  • Field template: select the default output function which can be registered with hook_ds_field_theme_functions_info(). 3 options are already available
    1. Default: this is the default Drupal core field output.
    2. Reset: a function which strips all wrappers.
    3. Expert: a function which enables you to have full control over
      • Outer wrapper, element and classes
      • Field items wrapper, element and classes
      • Field item wrapper, element and classes

Fancy pictures usually say more than words, so just take a look at the screenshots underneath to see how this looks in reality.

In case you're not satisfied with those 3 options, you can always create your own output function. It's a simple hook returning an array which keys are the function and values are used for the label in the select box on the Field UI screen. The function takes 2 parameters, namely the $variables from the field the $config variable which holds specific information about the field itself.

<?php
/**
* Implements ds_field_theme_functions_info().
*/
function example_ds_field_theme_functions_info() {
  return array(
'theme_example_field' => t('Example theme field'));
}

/**
* Field theming function.
*/
function theme_example_field($variables, $config) {
 
$output = '';

 
// Render the items without wrappers and label.
 
foreach ($variables['items'] as $delta => $item) {
   
$output .= drupal_render($item);
  }

  return
$output;
}
?>

And that's it. Theming your entities has never been so easy in Drupal 7. If you want to try out yourself, go to http://drupal.org/project/ds and download the latest stable release. Happy theming! If you're interested, please support our session at the upcoming DrupalCon London and talk with us maintainers for tips and tricks!

Fun with entities and Field UI: Views displays

Drupal 7 introduced entities. It's such a great concept, I'm able to easily port Views displays - part of Display suite - to Drupal 7. It is now part of the main package, bundled in a sub module called Display suite Extras, which also includes the 'region to block' and 'switch view mode on a per node basis' features. More goodies, less code, even more power. But back to Views, entities and overriding templates.

For those who don't know exactly what I'm talking about, a quick summary. In the Drupal 6 version of Views displays, you're able to select a single display of a view and rearrange the template variables so you don't have to override the views-view.tpl.php template file. It uses the drag and drop screen that Display suite comes with, but for D7 we decided to use the manage display screens that Field UI provides. This is great because it supports all entities, so any entity that is fieldable use the same forms in which we simply inject our extra regions. However, Views is not an entity, but in comes hook_entity_info to the rescue!

To make sure we can use the Field UI forms, we declare our own entity called 'ds_views', which is not fieldable and only has one default bundle.

<?php
/**
* Implements hook_entity_info().
*/
function ds_extras_entity_info() {

 
// Register a views entity on behalf of Views.
 
$return = array(
   
'ds_views' => array(
     
'label' => t('Display suite Views'),
     
'bundles' => array(),
    ),
  );
  return
$return;
}
?>

So now that we have an entity, we create our own menu callback function which will ask for the field ui form. Display Suite will call all additional fields and add the layout options too.

<?php
function ds_extras_vd_field_ui() {
 
module_load_include('inc', 'field_ui', 'field_ui.admin');
 
$build = drupal_get_form('field_ui_display_overview_form', 'ds_views', 'views', 'default');
  return
$build;
}
?>

However, when calling the Field UI form, we'll get a message saying this entity does not have not any fields. To solve that problem, we can implement hook_field_extra_fields and return one field. In this case, the title will be overridden later on because we also implement hook_ds_fields() which will return our fields for views. 

<?php
/**
* Implements hook_field_extra_fields().
*/
function ds_extras_field_extra_fields() {

 
// Register a single field so fields for vd be picked
  // up nicely in the display overview form.
 
$extra['ds_views']['views'] = array(
   
'display' => array(
     
'title' => array(
       
'label' => t('Title'),
       
'description' => t('Title'),
       
'weight' => 10,
      ),
    ),
  );

  return
$extra;
}
?>

In the screenshot you see a couple template variables which you can now put into the regions of the chosen layout.

Impressive isn't ? Hacky ? Well .. maybe a little bit. There is even more code, because now the combination of a view and a display is recorded as a bundle within the entity I just created above. I've recorded a short screencast so you can see it in action. If you want to try it yourself, download the second alpha release of Display suite for D7 and have fun!

Display Suite for Drupal 7: taking full render control over any entity

With CCK merged into core in what is now called Field API and the birth of entities, the possibilities of Display Suite and controlling the layout of objects have now become a much easier task than in Drupal 6. I've been working on the port since a good week now and got most things working with less code, but more goodies.

The biggest changes

  1. The module is now dependant on http://drupal.org/project/field_group, the new fieldgroup module Stalski and I (with the help of a few other colleagues) are now maintaining for Drupal 7. It defines a 'Region' format which DS uses to create any number of regions for your object. More info about field group is available in a previous blog post. DS is not dependant anymore on field group.
  2. The module now extends on the Field UI module, also shipped with Drupal Core. This UI gives you full control over the form and display for any entity in Drupal Core or defined in a custom module. This means default support for nodes, users, comments and terms without having to install any of the sub modules (Node, User & Comment displays) which existed in Drupal 6. It also means that we don't have to maintain our own interface anymore, because it's more mature now.
  3. It's now possible to create any number of regions. We ship with a couple of predefined layouts which have default css and a template file that can be (un)loaded in any occasion. HTML 5 will be a piece of cake from now on as we also ship with HTML 5 template files by default per layout. Defining or configuring the setup of custom template files from a module or the UI is easy and done in a few steps.

Previous implementations

As mentioned before, ND, UD and CD are not ported to Drupal 7 since they have moved to DS core. There is no consensus yet what we're going todo with the Node Displays contributions project as it holds some fine code for a couple of contrib modules, especially search and location. There's a big chance that code will eventually also move to this module, maybe as a separate sub module, the following days and weeks will make that more clear.

See it action

The code works, so go to http://drupal.org/project/ds and download the 7 development release. If you don't feel that adventurous yet, I've created a small screencast about the current working version, it only takes about 7 minutes of your precious time. There is a lot of polishing work todo, but I'm confident that we'll actually get a stable first release out the day Drupal 7 will be released.

Benchmarks for the Display Suite module

I've been promising benchmarks for the Display Suite module after every presentation I gave so far. It took me a while to get a good setup but now it's here. I've used the demo site as a start, so there are a lot of modules enabled for this test. Views, panels, fivestar, heartbeat, comment, taxonomy, location, gmap, imagecache are the most important ones since they all integrate with the ecosphere of Display Suite modules. I added a new content type called 'benchmark' and added 14 CCK fields to it: 4 textfields, 4 textareas, 2 images, 2 filefields, 1 node reference and 1 user reference. It also has a title, body, 2 taxonomy fields, a fivestar widget and a couple of comments. Depending on the test, the complete set of modules integrating with Display suite are enabled or disabled. These include ds, ds_ui, cd, hds, nd, nd_cck, nd_search, nd_fivestar, nd_location, nd_switch_bm, ucd, ud and vd. You gotta love small project names right ?

Desktop

The first test was ran on my Fedora Core 13 desktop - Intel Core Quad, 2 GHz, 2MB RAM with php 5.2.13 and eAccelerator - ab sending 100 requests with 5 concurrent users on a single node and page caching disabled.

 Without Display Suite
PHP 4.91 MB
Requests per second: 36.18 [#/sec] (mean)
Time per request: 138.202 [ms] (mean)
Time per request: 27.640 [ms] (mean, across all concurrent requests)
 Build mode blocked
PHP 5.31 MB
Requests per second: 34.68 [#/sec] (mean)
Time per request: 144.174 [ms] (mean)
Time per request: 28.835 [ms] (mean, across all concurrent requests)
 With Display Suite
PHP 5.33 MB
Requests per second: 34.51 [#/sec] (mean)
Time per request: 144.876 [ms] (mean)
Time per request: 28.975 [ms]
(mean, across all concurrent requests)

Server

The second test was ran on a CentOS 5.3 - 2 x Intel Core Quad, 2,6 GHz, 8MB RAM with php 5.2.11 and eAccelerator - ab sending 100 requests from my pc to the external server with 5 concurrent users on a single node and page caching disabled.

 Without Display Suite
PHP 4.25 MB
Requests per second: 26.91 [#/sec] (mean)
Time per request: 185.775 [ms] (mean)
Time per request: 37.155 [ms] (mean, across all concurrent requests)
 Build mode blocked
PHP 4.61 MB
Requests per second: 26.76 [#/sec] (mean)
Time per request: 187.072 [ms] (mean)
Time per request: 37.514 [ms] (mean, across all concurrent requests)
 With Display Suite
PHP 4.63 MB
Requests per second: 26.65 [#/sec] (mean)
Time per request: 187.642 [ms] (mean)
Time per request: 37.828 [ms] (mean, across all concurrent requests))
I knew that enabling modules would cause the memory of PHP to grow on both my desktop and the server. The server however behaves better in terms of keeping the requests per second steady per setup, so that's the real good news. I'll probably run some more in the future to see how it behaves in other situations, but I'm glad that I've got some results to show! You may lose a few microseconds, but win days of maintainability!

Drupalcon San Francisco and Display Suite


Due to Volcano activity on Iceland, I wasn't able to get to San Francisco for the biannual DrupalCon fest. But the Drupal community is that enthousiastic that we are setting up our own DrupalVolCon parties in Europe, already going on in London, Paris and in Antwerp. I'm supposed to give a session about Display Suite on wednesday, and that still might happen: we're busy testing and setting up streaming servers so we are able to stream our presentation on the internet at the time our sessions should take place in SF. All looks fine for now, so take that Eyjafjallajökull!

If you want to attend the session in Belgium, more info is available on http://belgium.drupalvolcon.com/

Update: we recorded the session and it's now available also on vimeo. Slides are at the bottom.

Display Suite profile

Related to our presentation, we just created a Display Suite profile containing all modules which are supported by Display Suite. We don't enable all modules by default in the installation profile, we just wanted to package them all, so you know what's possible.

We also packaged the Nodeform Columns module which enables you to organise your node forms in an easy way. If you don't really care about fieldgroups on the node form page, but need them on the front-end, you don't need to enable fieldgroups from CCK. The same applies to the tabs and cck fieldgroup tabs module, which are also included in the profile. Display Suite has this functionality by default.

You can see the full list of modules at http://drupal.org/node/775524, together with downloads of the profile and the packaged version of all modules with or without Drupal core included.

Important: some modules (like gmap and location) require the dev version to work properly, but for obvious reasons, the packed profile only contains official releases.

Anyway, sad I'm not there, but we're having fun here also!

Pages

Subscribe to RSS - display suite

You are here