Panels module: You ought to love it

On why Panels module is one of the greatest tools around and why you should really consider using it.

Photo of Pascal Morin
Fri, 2013-03-08 10:26By pascal

Panels is the kind of module that people usually either love or hate. In case you didn't guess from the title, I'm part of the first group and it is one of my must-install modules[1].
However, like many others, the first time I gave it a try, I just overlooked and gave up on it quickly. While it is now far more widespread than it was back then, there's still a lot of misunderstanding going on, more or less for the same reasons I had overlooked it myself, and with the same arguments against it coming back over and over.
I won't try to cover all pros and cons, but will attempt to clarify a bit what benefits you can expect and the most common misconceptions.

So, lets start with what I believe is the main source of misunderstanding, and the source of most other arguments against it: Panels' purpose, what it is and it is not.

"Panels module is a UI to place content on my site's pages"

That's too often the way people define it, and that's exactly where the trouble begins [2]. While not enterly false, this assertion misses the whole "bigger picture" and leads to two reactions:

  1. "How will my content producers understand how to use this overcomplicated UI"
    Let's get this straight out off the way: Panels is not made for end user content producers. It's for devs and site builders, and requires a good knowledge of how Drupal works.  Whoever told you differently has been misleading you [3].
  2. "I can code, I'd rather place content myself using template files, that's so much neater and lean than this bloated interface"
    Let's try to get what Panels is about: it is not about content placement, at least this is only a tiny part of it. To truly understand what Panels is at heart and its benefits, you need to picture it as a global, unified way to make various and heterogeneous Drupal "objects/thingies/concepts" interact smoothly together: menu router paths, entities, theme layer, views, …
    In practice, it means Panels loads what it calls "contexts", most commonly entities like users, nodes, taxonomy terms, and makes every element on the page content aware of these contexts. This allow for infinite flexibility in the display of elements on the page, such as changing the whole layout, displaying (or not displaying) a given element, replacing an element with another, etc. according to any properties of the loaded contexts. Typically, this means you can build a page without any hacky coding that would display:
    • an article node's body in its center column;
    • a separate "block" on the right column that contains the node's file attachments, available to certain user roles only, replaced with custom text for other authenticated users, and with the login block for anonymous users;
    • another "block" underneath with a view of the 5 last nodes in the same category taxonomy as the viewed node;
    • Use another layout for article nodes that have a "main picture" field filled up.

    You can do that, obviously, by other means than Panels, loading global $user, call drupal_render a couple of times and have a go at taxonomy_term_load and views_embed_view, get a bunch of checks in preprocess functions, maybe implementing hook_menu_alter to take over node's path, etc. [4] Results can range from the hackiest "stuff it all in template files" to more sophisticated and clean solutions, but in the end, you'll face the same problems: no reusability, plenty of code replicated all other the place as every different page will need some different checks, and a whole bunch of template files to maintain. The more complex your site gets, the more unsustainable this becomes.

    Think of it like Views. You could query the db yourself, render the results in various ways, here again with a range of solutions going from hardcoded html to proper calls to Drupal's rendering system, but only the foolish would do so. So much is provided by Views that you just go to the UI, build your view, export it and forget about it. Same goes with Panels: yes, you'll have to use the UI at some point, but don't you see the endless possibilities its flexibility provides?

    Well, I hope you do. So let's have a look at a few other common assumptions.

"Panels module is heavy, slow and suffers performance issues"

The answer is simply No. It's true that it will load what looks at first sight like a giant spaghetti of php objects, that will end up in memory. Beside the fact than most of these are already loaded by Drupal itself anyway, try to imagine the actual process: Panels loading all the contexts just once, passing them to each page element ready to use on one hand, versus on the other, each element on the page making its own computation to retrieve and load the same information everytime. Result seems pretty obvious, no? [5]

As a bonus, Panels ships with an efficient and granular cache system. For each path and variants, you can set cache settings for each individual element on the page: set it well and your page will be blazing fast.

"Panels module is redoing/taking you away from Drupal's core"

A more conceptual argument you sometimes hear. Panels unarguably adds some layers over some concepts, like menu router or content display, and drops some others, like blocks or regions. Truth is there's no choice but doing so, to be able to overcome the inner limitations of core. How do you expect to build something a system can't do itself without extending and overriding it? That is exactly what hooks are intented for. 
Now, what do you prefer: let Panels do this for you in a clean and unified way that retains Drupal's standards, or reinvent the wheel everytime in a way that will most certainly be clunky and difficult to maintain, that no one but you can understand and that you yourself probably won't understand anymore in 6 months? I've made my choice.

If the scope of Panels is becoming a bit more clear for you, let's see a few more cool things it provides. There's much more, but these seem key to me:

  • Exportable in code: if you use the "zero-touch" approach, everything's exportable using CTools, hence Features, even custom content. Compare to core's blocks!
  • Tight views integration: Panels is able, when set on the view, to override some of the view's settings. This means you can do any crazy thing you might want: changing the number of results, altering arguments, pagers, whatever, based on context.
  • Extendable: You can write your own plugins or handlers for anything Panels doesn't provide out of the box: contexts, displays, variant types… To be honest, it means you'll have to learn a bit there, and depending on what you're trying to do, documentation might be "light" on certain subjects.
    However, in 99.9 % of the cases, the only things you will ever need to code are: 
    1. layout template files (Oh, back are our beloved template files, yay, known territory!)
    2. content type plugins, for custom "panes" which are the equivalent of creating a custom block type using hook_block_info, and quite trivial to create.


I shall try to sum-it up. Tricky. Probably the main thing to keep in mind is this: If you consider Panels as a UI to do your theming job, you'll be disapointed and frustrated. If you take it as a powerful new way of architecting and building your site, you'll be delighted. 

So yes, you will need to learn a few things and new concepts, but believe me, it's worth it.


1. Lot of this is in reality about ctools' « page manager » module and not panels per-se. Given the common confusion between both and for clarity, I've chosen to make no distinction and used the name « Panels » everywhere, although it renders this whole post technically innacurate. However, my point here is that if you're able to tell the difference, you probably don't need to read it! Please forgive me.

2. That's also more or less the way it is defined in the first paragraph of the project page, « Panels overview », which is sadly probably all most people will read from the entire description.

3. Yeah, there's panelizer and IPE. I know. Just trying to keep it simple.

4. You could also use a combination of other modules (context, boxes, display suite, themekey, beans,…). This is perfectly valid in certain cases, and you can combine most of them with Panels, see James talk on DS for example. But out of scope here.

5. Performance of Panels