Thinking outside of the Block: Drupal Layout tools in the Real World

 This blog post is an introduction to what will be a multipart series.  Although there is no shortage of posts and discussions of layout solutions for Drupal, there is a lack of a comprehensive overview of the available module options for layouts in Drupal, and we are aiming to remedy that.  We will both outline what the current state of the art is, and discuss what approaches might provide an easier migration path to Drupal 8. In this series, we will draw on our real-world experience building and maintaining sites using each of the major solutions available. We want to present this content in bite-sized chunks, highlighting what you need to know about each system, and discussing how to meet common use cases. 

We have an audience in mind, specifically, Drupal site builders that want to get beyond blocks and regions, and start doing really awesome things with their layouts. This of course, should be without having to ever get into code.

At this point in the Drupal 7 life cycle, there are at least three really solid layout module options available to a site builder.  The three Drupal modules that we will address, with one post per module, are Context, Display Suite, and Panels.  Given that we are focusing this series on site builders, and specifically avoiding solutions that require writing code, we will not get into php templating.  We will also talk about some of the available extra goodies that are out there for panels, such as panels everywhere and panalizer, and wrap up with an overview post that points us forward to Drupal 8, and future proofing your layout choices.

The difficulty that one encounters when embarking on a series like this is the sheer quantity of information that surrounds every level of the topic.  It would not be difficult to come up with a ten part blog series that discussed only panels, in fact the difficulty would lie in keeping it to only ten posts! It can also be really difficult to compare Drupal modules that do similar things, without actually downloading them and learning them all.  Ain't nobody got time for that.  So we've decided to structure the posts as follows:

Part 1. Give as broad an overview as possible of the strengths and weaknesses of the module in question.  Specifically, talk about how easy/difficult it is to get started with, and how flexible/powerful it is with an eye towards meeting more and more complicated use cases.

Part 2. Introduce the module, with some screenshots of how the UI works.  We will use two specific examples of common client requirements, (the same examples for each module), and step through how to fulfill the requirements, with screenshots.

The Examples:

1. An extremely common requirement is to have a two column layout for the node display of a given content type, with individual fields in separate columns. Seems like a simple request, yes?  It's not possible with regions and blocks.  This is simple enough to do with a node template, but in order to preserve flexibility for site builders and even content editors, we've decided that we don't want a solution that requires writing PHP.  This is something that is (dare I say it) simple to achieve with any of the three modules we are highlighting, and we will step through how to do it.
2. A more advanced (but still common) use-case is to have layouts that react to various conditions. For instance, you may need to have different layouts for public and private events. The “out of the box” solution might be to make separate content types for each. However, this is not semantically accurate, and creates difficulties when a content editor wishes to turn one into the other. These systems all have the flexibility to meet this requirement.

These two use examples hardly scratch the surface of what can be done with these modules However, we hope that they will get you interested in the possibilities, and an idea of which system will best meet your needs.