23rd July 2014

Coder Lounge - July 2014

John Ennew
Technical Director

Display Suite

In this month's coder lounge, we spent some time discussing the merits of the Display Suite module. This came about as a result of the development team wondering "what still puzzles us" from a recent project retrospective.

Display Suite provides a huge amount of functionality, allowing the user to modify the markup of a rendered node and its fields.

We've used display suite as part of our core toolkit for a number of years but recently found it getting quite bloaty. Also, it feels like it interferes with the way we work. Our design team gives us static HTML and CSS, which we need to convert into templates. The more abstracted from the template code you get, the more complex the conversion from flat HTML/CSS to Drupal theme becomes.

Display suite is great but we've found it involves too much work in the GUI and exporting changes to the live site involves using the Features module to export then revert on the live site. This is looking quite costly in time, compared to directly modifying a template file.

Display Suite is good if you are building your website yourself or if all the site building is done by Drupal developers. If you have front end people (who know HTML/CSS/JS) on your team, they'll find themselves asking the Drupal developers to do things which they could have done directly in a template file.

This connects interestingly with the current Headless Drupal initiative, which is trying to separate the front and backend components of Drupal to allow front end to grow independently of the backend and not be constrained by it. Doing this frees the front end developers to build, modify and experiment freely, making them less dependent on others in the team and, hopefully, able to create more interesting websites.

The alternatives to Display Suite

What are we considering in place of Display Suite? The main things we use display suite for are: custom fields, custom view modes, modifying label text and stripping Drupal HTML from templates.

  • Custom fields can be defined in code using hook_field_extra_fields
  • Custom view modes can be provided by the entity_view_mode module very nicely.
  • Custom field templates can be defined using the Fences module. This provides the ability to select a field template for a field in the same way one would select a field formatter. The settings for this get stored with the field exportable.
  • Modifying the label text is not something that happens often, the label would usually be the same as the field name but would most likely happen in a theme hook.

So, to Display Suite or not to Display Suite? The alternative to the Display Suite mega module appears to be several smaller modules, but doesn't that just add up to the same thing? We are in the process of trialing the alternatives mentioned above and will be reporting on our findings as to how much effort is saved.

Paragraphs

We also looked at the Paragraphs module as a light weight alternative to tools like Panopoly. With Paragraphs, the developer builds different paragrpah types, which can be added in any order to any node with a parapgraphs field attached. Each paragraph type is an entity itself, with its own fields which can be added directly on a node edit form, this is similar to how field_collection works, if you are familiar with that, except you get to pick and choose different bundles for an individual node.

Paragraphs could be:

  • A block of rich text
  • An image
  • A video
  • A map
  • Something more complex, like a carousel or reference to a view, or indeed anything else you can normally do with a node.
  • A single paragraph which combines multiple elements, such as an image floated left with a block of text on the right

Using Paragraphs allows a content author to build up a page from different components in different orders. It also may address the problem of inserting media elements into the WYSIWYG editor in Drupal. Adding an image into the WYSIWYG window is possible but what you get as output is variable and there isn't really a good way to know what media is actually embedded in a given node if its been done via the WYSIWYG editor (yes, Media does provide this but we've never been 100% confident in the results as yet).

We liked the simplicity of the approach that paragraphs gives and will be using it in some projects over the next few months, stay tuned to see how we get on!