I'm working through some layouts that aren't entirely complex but are definitely outside of the core Drupal provides.

It really does seem like there a 20 ways to do one thing in Drupal.

Should you edit .tpl files with different regions for specific content types and nodes, or should I just stitch everything together with Panels?

I have this fear that Panels would make everything more complex and start to bog things down from a performance perspective.

  • Complex yes, performance concerns not so much. Only add that complexity if you are sure you need it. – Mark Ferree Aug 4 '15 at 17:32
up vote 6 down vote accepted

Panels module

"Learn Page manager" is an interesting / amazing set of videos. They contain various topics related to the Panels module. After you reviewed these videos, you'll understand that it'll be hard to come close to all the features that come with the Panels module.

Here is a summary of the entire set of videos about this topic (quote from the link above):

  • Page manager allows you to collect and manage contextual information in a flexible and consistent way. It is an important part of building infrastructure on Drupal websites, and you should know how to use this module.
  • The screencast series is targeted at experienced Drupal developers.
  • Episodes 1, 2 and 3 introduces the most basic concepts, such as custom pages, variants, selection rules and (to some extent) contextual objects.
  • Episodes 4, 5, 6 and 7 talk about Panels, with emphasis on Views integration but also some words on efficient caching.
  • Episodes 8 and 9 about access control, menu items, and not least the little-known but very useful Contextual Administration module.
  • Episodes 10 and 11 talks more about using contextual objects in Page manager, including using Views as context. This is, imho, where the real power in Page manager is.
  • Episodes 12 and 13 collects various bits and pieces, such as how to use Panels to easily rearrange the node edit form, import/export settings, and some extra modules that can be used with Page manager.

Refer to Explaining Panels: An Overview for Drupal Developers for another great explanation about Panels.

Some more words about Page Manager:

  • In Drupal 8, Page Manager has become a separated module, while formerly (up to Drupal 7), it was part of the CTools module. Here are some more quotes from the (D8 related) project page:

    It supports the creation of new pages, and allows placing blocks within that page.

    Like Drupal 7's Page Manager, it provides a concept of "page variants", each with their own selection conditions.

    Additionally, it can be used to take over an existing page, like overriding /node/% to change what is displayed when viewing a node.

    It utilizes the core Conditions, Context, and Blocks APIs to accomplish this.

  • In Drupal 7, Page Manager was the foundation of the Panels module.

Bean module

When talking about layout in Drupal, one often brings up "Blocks" also. If you also use the (great) Bean module, it'll open lots of new possibilities. Here is a quote about it (from its project page):

Think of a Bean as a method to provide new types (compared to node this would be a content type) which then provides an add content interface to create as many blocks as you require (see screenshot below). The bean content can then be placed around the site just like any other block.

The video tutorial Drupal Bean module tutorial - using Bean Admin UI provides a great introduction to really understand the power of this module, and the kind of things you can do with it (by only using site building techniques, no custom coding involved). It also shows how the Bean module transforms Drupal blocks into fieldable entities.

Refer to my answers to the question about "How to control Block revisions before being published?" for more details about the Bean module (things you can also do, etc).

PS: The Bean module only started as of D7 (because of the "entities" of course that were only introduced in D7), and already has over 22K reported installs. AND it has been integrated (already) in core in D8 (refer to this issue for more information). Those who don't use it yet should definitely start looking at it in preparation of some day upgrading to D8.

  • Thanks for pointing me to that set of video. Maybe I should ask this as a separate question, but do you have recommendations for learning more about Contexts. I have trouble getting the idea of a Context without relying on a Vocabulary and Terms. – Erik Hanson Aug 3 '15 at 1:07

I used to use panels for everything but have since switched back to tpl files - even for fields - simply so that changes to the site look and layout can be tracked in code and versioned using git. I have even stopped using regions and block all together. Any views or blocks (from modules that provide specific stuff like the profile completeness module) that I need are called in code and access checks are either in code or via view configuration.

The key is a well organized folder structure in your /templates folder.

If you have non developers needing to make layout changes however, then I would use panels.

  • 1
    I use the Features module to track the Panels configuration in code. Update, commit, push, revert, bam. – Queenvictoria Sep 30 '15 at 9:44

I certainly resisted the Panels module for a long time. But then I bit the bullet and drank the koolaid and now I definitely will never go back.

Instead of a templates/ directory stuffed to the hilt with overrides I usually just have one file (to remove a colon or something silly). I have a panels/layouts directory with one or two layouts that are a bit funky with a couple of extra classes to help the theming. And I have a bunch of features.

I think layout is one of the smaller tasks that I now rely on Panels for. More powerful are:

  • the per role layout selectors,
  • the visibility per pane,
  • the CSS selectors per pane (making my component based CSS stretch much further)
  • the super super tight Views integration.

Every now and then there is a kink in the road. But by and large it's a much (much) cleaner experience.

  • I haven't really worked with Layouts much. Looking at them quickly, they look like .tpl files that are then usable for Panels pages. So it seems to me that it makes templates that you would normally write more "available" across content types and nodes. Am I understanding that correctly? It that's true, that's pretty awesome. – Erik Hanson Aug 3 '15 at 1:04
  • There are a lot of things panels can do. Different layouts per type and or role. Blends of content types, views and blocks. Permission based content. The custom layouts you create are only needed if the (many and useful) default layout styles still aren't enough. The panels system, even without your own custom layouts, will do more, cleanly and efficiently than your old TPL files ever will. Drink the koolaid and junp in. – Queenvictoria Aug 3 '15 at 8:06
  • Thanks for your help. I'm curious, do you use panels for everything or just tactically for things that makes sense? Playing around today, I could see using layouts with context (as part of omega) for some things, and then panels for others. Are there pitfalls in a mix like that, is it safer to stay one or the other? – Erik Hanson Aug 4 '15 at 0:01
  • I use Panels internal context exclusively (not the Context module). And yes: I use Panels (or Page manager as Pierre indicates) for everything due to its power in quickly customising content and layouts. In some rare cases (mostly administratively) I will use a Views page. But usually that View would be wrapped in a Panel anyway. – Queenvictoria Aug 4 '15 at 5:57

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.