Skip to content Skip to navigation

Why Not Panels?

One of the common requests that we receive about the list of included modules in Stanford Sites is if we can add the Panels module. I would like to outline our rationale for not including Panels in Stanford Sites, and describe the alternative approaches and methods you can use to create unique, custom layouts on your website.

What Is Panels?

"The Panels module allows a site administrator to create customized layouts for multiple uses. At its core it is a drag and drop content manager that lets you visually design a layout and place content within that layout. Integration with other systems allows you to create nodes that use this, landing pages that use this, and even override system pages such as taxonomy and the node page so that you can customize the layout of your site with very fine grained permissions."

(from the drupal.org project page for Panels).

Panels is a very robust and powerful module that has deep integration with modules such as Views, Features, Chaos Tools, and Taxonomy. It has a sophisticated caching mechanism, a powerful in-place editor (IPE), and a rich ecosystem of add-on modules. There even is an entire distribution built on Panels.

Screenshot of the Panels module's user interface for choosing different page layouts

(Screenshot taken from Earl Miles's blog.)

Planning for Drupal 7 on Stanford Sites

Stanford Sites launched in Fall, 2011, with Drupal 6 as the only offering. In June, 2012, IT Services staff did a survey of the various page layout approaches available in Drupal 7. We included Panels in this survey, as well as a competing approach, that of Context and Display Suite. We also reviewed several other modules that attempted to address layout in various ways, including BEAN, Boxes, Delta, and Organic Groups.

Pain Points in Drupal 6

We began by listing our "pain points" in Drupal 6:

  • Blocks are "dumb" - they have no knowledge of what content is at a given path
  • Revisioning: blocks do not track revisions
  • Blocks don't have instances (i.e., cannot be placed multiple times)
  • Cannot assign id or class to blocks (only to divs within blocks)
  • Writing PHP, HTML, CSS – many users do not want to do this, and should not have to

Themes and Regions

Stanford Web Services (SWS) uses the Open Framework theme (and subthemes) extensively. Our responsive web design approach is based on placing blocks in regions within that theme, and dictating how many columns blocks will span. Since blocks and regions are native to Drupal and a relatively simple concept for people new to Drupal to learn, our themes take advantage of a user's familiarity with blocks and regions to enable quickly building responsive sites.

Diagram of the responsive flow of blocks and regions in the Open Framework theme

Context and Display Suite

The Context/Display Suite approach builds on our core responsive theme strategy of using blocks and regions, and offers solutions to the majority of our pain points without introducing unnecessary complexity:

  • Context solves the "blocks are dumb" and the "multiple instances" issues by allowing you to create "layout" configurations (for use site-wide or for specific pages/paths) in which blocks can be reused and placed in different regions in each layout
  • Display Suite also allows creation of custom layouts and view modes, and provides the ability to create blocks out of node fields (thus enhancing our blocks/regions strategy)
  • The Block Class module is a lightweight way to solve adding classes to blocks and allows us to take advantage of Open Framework's responsive grid system (e.g. "span6" gets you a block of 50% width)
  • Context and Display Suite have Features integration, which allows us to export layout and configuration (and track in a VCS)

Panels

The Panels/Panopoly approach is compelling, and offers a rich set of end-user tools. However, several factors contribute to our decision not to include it in Stanford Sites at this point:

  • There is a significant learning curve to Panels. With robustness and flexibility come complexity, and this presented an obstacle to launching the Drupal 7 environment quickly, and an impediment to self-service users of Stanford Sites.
  • It is an "all-or-nothing" option, in that Panels completely takes over the display of the page
  • Although improvements have been made to the administrative UI since previous versions of Panels (particularly the Panels in-place editor [IPE]), it is still a very complex interface
  • The responsive benefits of Panels are offset by SWS's heavy use of our base theme, Open Framework and its responsive block regions

In summary, we have taken a core "blocks and regions" approach to layout, and found solutions in a combination of modules: Context, Display Suite, and Block Class. This allows for flexibility and simple layout implementation without the learning curve or overhead of Panels.

Additional Resources

Comments

I think you make a good choice. I also use context and display suite, both are a good combination to create html structures (although I have not had much luck with imports and exports with features). Thanks for the article.

I found this article very interesting and useful. Recently I started using the Open Framework Template and is really easy to use.

One thing you didn't mention is about the performance cost by using Panels, also, the heavy div tags load (at least in Drupal 6).

Thank you guys to share your experiences.

block is not deployable !! People sometimes treat blocks as content, but i just don't understand how. IMHO, block should be configuration settings at the first place, similar to views, this is why panels is good in this regard.

Yee gads, panels is way easier to set up and manage than the combination Context+Display Suite.

My sympathies to those who have to work under this regime.