Using Panels for Layout versus custom .tpl files

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.