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.


Kristof Van Roy on Wed, 03/11/2010 - 09:36

Damn, think of all the possibilities. This opens a can of new features.

Great work!

Rene Bakx on Wed, 03/11/2010 - 09:54

Woot, this sounds like a very interesting development to make it a whole lot easier to theme a site. Nice job!..

yched on Wed, 03/11/2010 - 10:09

Happy to see how DS can both flourish and simplify its code in D7 :-)

I fail to see the meaning of having draggable "region rows", though.
The regions semantics is hardcoded in layout templates, so it seems there are a couple UI operations that are at best meaningless, at worst produce strange or broken results :
- dragging 'Footer' between 'Left' and 'Right'
- dragging 'Left' inside 'Right'
- placing a field directly at top-level between 'Left' and 'Right'.
- dragging 'Left' to the 'hidden' section

I originally thought DS "regions" would fit into the $form['#regions'] that were added in Field UI's overview forms - non-draggable and all-inclusive sections, just like on core's block admin page (and like in DS D6, right ?). I know you guys are aware of '#regions', so I'm pretty sure there are compelling counter reasons for using regular draggable rows instead, just wondering :-)

swentel on Wed, 03/11/2010 - 10:50

@yched There are a few reasons yes :)

  1. We want the complete 'rendering' and 'region' concept into field group so 2 modules don't have to do recursive functions - although we could move the 'region fieldgroup type' maybe to DS - but that's saying to the rest of the world, regions are only possible with DS, which is not our intention.
  2. Re: the $form['#regions'] key, we're not sure if it's a good fit because the main problem is that we really would like to see another column called regions in the field UI and it currently clashes with the 'format' column which has the notion of 'hidden' vs 'formatted'. So that means a lot of PHP and javascript overrides
  3. Regions don't have settings and we want extra classes on them through the UI.

We're looking for a way to nicely hide the drag handler on what we call regions, so you can't make mistakes and some nice javascript too so that everything is nested underneath :)

If we ever decide to go for patches for Drupal 8, let us know, we'll be assisting you with a lot of patches :) Fact is, the changes are really small, but at this point to late to get into Drupal Core. I'm sorry we didn't jump on this earlier so we could help you more with the DS 7 version!

Alejandro Garza on Wed, 03/11/2010 - 16:28

This is awesome stuff!

A suggestion: It seems that, although the module's name is "Display Suite", it would make more sense to add it to the "Structure" menu as something like "Layouts" or similar. IMO it'd make more sense and less WTF to an admin ("I know what a 'menu' is, but what is a 'DS'?).

yched on Wed, 03/11/2010 - 23:52

@swentel :

"hide the drag handler regions rows"
The rows will still be orderable wthout JS, or when users click the 'Show row weights' JS link.
Also doesn't prevent dragging a field between two regions.

"#regions mean non-negligeable PHP and javascript overrides"
true :-/

jayendra on Thu, 22/03/2012 - 11:13

I have not use display suite yet now. But I hope in Drupal 7 it will be provide some great functionality.

Add reply

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
Have you written a response to this? Let me know the URL by sending a webmention.