Explaining the Panels module

Welcome to this week’s Secret Sauce, a short podcast by Palantir.net that offers a quick tip on some small thing you can do to help your business run a little bit better. Today’s advice comes from one of our colleagues at Pantheon. Steve Persch is an Agency and Community Engineer at Pantheon and former Palantir team member, and he’s sharing his thoughts on using the Panels module in Drupal.

Transcript

SP: Hi, I’m Steve Persch. Today I’m going to be talking about Panels Module in Drupal. 

So I use Panels Module because I think of it as a really direct way of doing style guide driven development, which is a topic that’s getting discussed a lot in the Drupal community these days. Style guide driven development is the idea that development is directed by a style guide understanding of how a site is put together. What I mean by that is components like global headers, global footers, the styling of teasers, the styling of common article header elements is a really accessible way for clients, for stakeholders to conceptualize the visual understanding of a site. 

So if you’re starting at that point with a style guide and you’re working in Drupal, it can be difficult to make Drupal match the markup that’s present in the style guide. A lot of Drupal developers like to complain about the CSS classes, the excessive wrapping divs that come from Drupal, and there’s this pain point of “how do we get Drupal to print the markup that we want.”

At DrupalCon Los Angeles I did a presentation called Rendering HTML with Drupal: Past, Present and Future. Anyway, in that I described how in earlier versions of Drupal it was really common to just take whatever markup you get from Drupal and write CSS against that. It may have too many divs, too many classes . . . it doesn’t matter, just write CSS against it. As we move towards this world where where we’re doing more style guide driven development, we generally don’t want the markup that comes out of Drupal by default.

Here’s where Panels Module comes in. Panels Module, I think, is a great mapping layer between Drupal’s internal understanding of elements like nodes, like headers and blocks, and that style guide understanding. So Panels has this concept called the Layout PlugIn. The Layout PlugIn is that mapping layer between a Drupal template file and the style guide design component. So you may have a Layout PlugIn called Global Header, and that’s your global header design component. You can then use that Global Header layout plugin at all these different layers of Panels.

There are four main layers of Panels that I like to use. There’s the Mini-Panels Layer, which is analogous to core’s block system. A mini-panel is basically an individual block, so you make an individual block, and that’s your site header. You can look at that mini panel and you can see this uses the global header design component and that becomes a mapping layer between . . . all right, we had this understanding of a design component called a global header, and we had to plug in all this Drupal data like search forms, like menus . . . Panels is a user interface that lets you insert all of that Drupal data into a template that you can still think of as an independent design component.

Doing that in traditional Drupal is really hard conceptually because in a more traditional Drupal build, the header might just be a conglomeration of things in the global template file, your page.tpl file. And it’s hard to keep track of where does this design component start and stop? Is there even a single representation of the header, or is it just a mix of menus that are thrown into the global template? 

So with Mini-Panels you can encapsulate blocks. With the Panelizer level, you can encapsulate view modes. Panelier is essentially an alternative user interface on top of Core’s view modes. So in Drupal Core you have the ability to say, “this article teaser is going to display these fields in this order, drag and drop . . . cool. I’d still like to have that mapping layer too. Well, our style guide says article teasers are really illustrated list items, our style guide calls them illustrated list items. So we can map in Panelizer from the Drupal concept article teaser to the style guide concept illustrated list item.

The next layer up is the Page Manager level. This is basically: what is this page? If you have a page that’s your taxonomy term listing page . . . you’ve got a vocabulary of musical genres . . . you’re going to have a page that is genres/jazz. What happens on that page? If you just have Drupal Core, that page is going to be nothing but a list of all nodes tagged in jazz. But your style guide says jazz needs to show this design component, it’s a complex design component. It shows the most popular albums in jazz, it shows these songs, it shows artists, it shows all these different things and we have a name for that component. At the Page Manager level you can map the Drupal concept of jazz page to the style guide concept of whatever is the name of that design component . . . maybe you call it genre landing page. So that’s our third layer, the “what is this page” layer.

Finally there’s the global layer [Panels Everywhere], where you do things that in Core that you would otherwise do with the Core blocks system. We’ve got a global header, we’ve got a globar footer, maybe we have a global sidebar . . . panels everywhere lets you control that global template and use all the Panels UI niceness to line up your variables to say, “actually on this page we have no global header and footer whatsoever, we have just this one element. On this other page we have a variation that says we use a mini-header.” Panels Everywhere is a way of more deterministically saying how those variants shake out, whereas in Drupal Core all of your core blocks are responsible in and of themselves for figuring out, “do I show up on this page?” With Panels Everywhere you can say on a given URL, on a given pattern this is our global template, this is our global design component. 

That’s why I like Panels. If you want to know more, check out the Palantir blog. I’ve basically given a summary here. There’s one blog post explaining Panels that runs down these four concepts, these four main modules, and then there’s another follow-up blog post called “Why I Use Panels” that digs a little deeper into the concept of mapping between Drupal data and a style guide or independent representation of design.

AM: Thank you Steve. That’s the end of this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at palantir.net. Enjoy your day.