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 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.
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)
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.