An Overview of the Drupal Panels Ecosystem

I’ve recently been converted to the idea of why you would want to use Panels in a Drupal site. There is a lot of documentation out there on the very particular pieces of Panels.

As someone new to Panels, what I have found frustrating is lack of a larger overview of how all the pieces fit together. This post is meant to be a rough overview based on what I’ve discovered in a short amount of time. I hope this serves as a handy way for others new to Panels to get a sense of the landscape.

This is not an exhaustive list. These are merely the modules that have seemed useful. These are also not all required – it depends on your project needs.

This is not going to be a tutorial on any one module, but more of a big picture overview of how they relate. I am still learning about Panels, so some of this might be incorrect, or poorly paraphrased. I will try to update this post as I learn more.


I’m going to assume you are experienced with building Drupal sites, yet are unfamiliar with the ecosystem around Panels. I am going to assume you understand terms like “node”, “content type” and “view”.

Required by Panels

  • Chaos Tools (CTools) – this is the one module that Panels lists as a dependency. Being that Views also requires CTools, odds are your site already has this installed.
  • Page Manager – This isn’t actually required, but you really wouldn’t want to use Panels without it. This is actually part of the CTools suite of modules. It provides the contextual logic that is typical in a Panels-based site. This is the module that allows you to say “okay, at this URL, do this” or “when displaying this content type, do that”. It doesn’t necessarily need to be used with Panels, but that is the most typical use case.

‘Core’ Panels

When you install the Panels module, these are the pieces that come with it.

  • Panels – Panels itself is the underlying module that facilitates a more powerful layout system than Drupal provides out of the box. It allows for the switching of layouts for content – in something called a “panel”, as well as arranging content using “panes” within a panel. The Panels module itself, like Views, provides no UI out of the box. One of the other modules that comes with it needs to be enabled.
  • Panel Nodes – This is the module that allows you to create nodes that are, well, panels. For me this was one of the more confusing aspects of using Panels. The idea is that you create a content node that is purely a panel. It’s not a typical Content Type, it just holds other content. This allows for things like creating a special panel for your site’s homepage, which might be an assembly of views, feeds or other content.
  • In Place Editor (IPE) – This module adds a more intuitive front end interface for managing panels and panes. For content administrators it adds a black bar at the bottom of every panel with two big buttons – “Customize this Page” and “Change Layout”. When used in conjuction with Panelizer, this can create a much more intuitive content managing experience, as compared to the normal (admittedly dense) Panels interface. If a content type is configured to allow it, every node can be overridden on a per node basis, which means that using the IPE, a content editor can navigate to a node, hit “Customize this Page” and add more content, or change the layout entirely.
  • Mini Panels – This allows you to create panels that can be used inside other panels, or within Drupal’s default block system. I’ll be honest, I haven’t used this one much, so I can’t really elaborate on it.

Powerful Add Ons

  • Panelizer – This allows you to make panels out of any kind of Drupal content. What tripped me up was that I grabbed this module when I first experimented with Panels, so I didn’t understand the boundries of what Panels did out of the box, and where this took over. Basically, if you define a content type, this module allows you to then take those nodes and make them into panels. Then you can attach other panes to those nodes. This also is the module that allows for overriding of panels layouts and content on a per node basis, which is very powerful.
  • Fieldable Panel Panes – This module allows you to create pane types that can have fields, just like a content type. If you are familiar with BEANs, this is pretty much the same concept, just with a different entity type. Also, once a pane type is used to create a pane, that pane can be reusable elsewhere on the site. An example could be a photo gallery pane type, with image and caption fields, which could be used to create a product gallery pane. That product gallery could then be placed in multiple areas of the site very easily. As of this writing, in August 2014, I would recommend using the Dev branch of the module, which is quite a bit more developed than the stable branch. The final pane entity type is more intuitive to use.
  • Panels Everywhere – This could be considered the ‘logical conclusion’ of using Panels for layout. With this module enabled, you can completely replace Drupal’s block system, and use Panels to compose all of your content pieces. In fact, it’s recommended that if you use Panels Everywhere, you should disable the Drupal core Block module. If you’re familiar with Drupal theming, another way to think of it is: Panels sort of overrides node.tpl.php, while Panels Everywhere overrides page.tpl.php.
  • Display Suite – This may seem like an odd module to list here, as many consider Panels and Display Suite to be an either/or proposition. However, they can be used in conjuction, with each being used for their strengths. Display Suite does many things, but at it’s core it lets you define new view modes (in addition to Drupal’s default “Full Content”, “Teaser”, etc), and lets you define how those view modes are displayed. You can have very granular control of field markup, or node layouts. I personally find it’s approach to layout to be very unintuitive, so it makes sense to use Panels to control layout, but Display Suite to define discreet elements of your content display.

Improving Panels Markup

One of my largest hang ups in not wanting to use Panels was the markup it produced. Out of the box, Panels added to Drupal’s div soup in a way that I couldn’t abide. Thankfully, there are two modules that are out there that aim to help reign in Panels’ markup so my inner standarista can sleep at night.

They both work in the same way – when accessed through the full Panels content interface (as opposed to the IPE), you can add a ‘style’ that can be applied to a pane. Within those style settings, you can decide what kind of element wraps the title, if a pane has a wrapper div or not, or whether it should be some other kind of element instead of a div – e.g. nav, section, etc.

  • Semantic Panels – of the two, this module provides more extensive options. In addition to choosing wrapping markup, you can add things like tabindex, ARIA Roles, and more to the content of a pane.
  • Clean Markup – this has a simpler set of options, though any additional attributes (like ARIA Roles) can be added manually. You’re probably going to get 98% of the same results as you would from Semantic Panels. Clean Markup actually consists of three modules – a core Clean Markup API module, then two add ons – one for Panels, one for Blocks.

I believe there is some thought to combine these two modules, as they overlap so much.

Conclusion (not really)

As I said, this is not meant to be an exhaustive, or prescriptive, list. I welcome input on what should be included here, and corrections if I’ve mischaracterized anything.