Last updated 2 June 2017. Created on 23 March 2015.
Edited by tz_earl, nerdcore, imadalin, japerry. Log in to edit this page.

What is Panels, and why is it awesome?

  1. Panels allows a site admins to create customized layouts for multiple uses.

    • At its core it is a drag and drop content manager that lets you visually design a layout and place content within that layout. Integration with other systems allows you to create nodes that use this, landing pages that use this, and even override system pages such as taxonomy and the node page so that you can customize the layout of your site with very fine grained permissions.

  2. Panels supports styles straight from the styleguide

    • Styles can be added or changed on individual content panes, regions within a panel, and the entire panel will be rendered.

  3. Features a layout builder

    • Optional, this is nice for visually designing a layout. Modules and themes can provide custom (responsive!) layouts that can fit a designer's exacting specifications, but still allow the site builder to place content wherever you like.

  4. Panels uses Contexts - What are they?
    • Panels 3 utilizes the CTools' system of "context" so that the content you place on the page can be aware of what is being displayed. For example, in the existing Drupal setup, a block has no real knowledge of what the primary page is displaying. There are all kinds of tricks and tools you can use to get information to the blocks, but this generally means writing PHP code to scan the URL and pull the data out, which is not a very good thing when that data should already exist.

      In a Panel, you can create contexts, which represent the objects being displayed. For example, when displaying the node view, NID argument on the page is converted into a context through the 'arguments' system. You can then create a relationship from that node to, for example, the node author, or to another node via entityreference. Once the contexts are in place, content specifically about those contexts can be placed.

      In addition, these contexts can be checked for information and use that not only to make content available to be displayed, but to choose which layout to display! For example, if your site is multilingual, you can use context to see if the node being viewed is set for a particular language and choose to display it one way if it is in French or another way if it is in English. You can also select on attributes like node type, whether or not the user has access to edit the node, and more. This system is also pluggable and you can add your own custom criteria with only a small amount of code. Want to display nodes differently based on how a custom field you've added to a node type is set? That is very simple to write and you can use this to change the presentation entirely.

  5. Panels includes a pluggable caching mechanism.

    • A single cache type is included, the 'simple' cache which is time-based. Since most sites have very specific caching needs based upon the content and traffic patterns, this system was designed to let sites that need to devise their own triggers for cache clearing and implement plugins that will work with Panels. Panels can be cached as a whole, meaning the entire output of the panel can be cached, or individual content panes that are heavy can be cached.

  6. Panels can be integrated with Organic Groups

    • Using the og_panels module, you may allow individual groups to have their own customized layouts.

  7. Panels integrates with Views

    • This allows administrators to add any view as content. Or, for uses where the layout editor needs more tightly controlled content, Views can be given custom displays to provide only what the site administrator wants the panels builder to use.


Ok, I want to use Panels! There are lots of options though, how do I know where to start?

  1. Panel nodes

    • Think of them as a new content type in which you can create nodes.

    • They behave just like regular nodes in that they appear in the Drupal admin/content list, and are searchable just like regular nodes.

    • Individual fields can be added to this content type, however they exist outside of the panels layout builder

    • It would be better to add fieldable panel panes can be added to the panel display

    • The main difference is that you may add custom text or images to each panel node, beyond the defined fields, which you may add to this content type.

    • They do not have options related to variants, access control, or selection rules.

    • They would probably be used for snowflake pages

  2. Panel Pages (with variants)

    • Panel pages are completely separate from the idea of traditional nodes.

    • They do not show up in the Drupal admin/content view

    • These pages have a URL path, accept arguments and can have menu entries.

    • They offer more complexity:

      • Variants - Different versions of the same “page,” depending on selection criteria. E.g., for the “node_view” page, select variant by content type.
      • Selection rules - Control the criteria used to decide whether or not a variant is used.
      • Context - Add additional context objects to this variant that can be used by the content.
      • Access control - This is a nice advantage over nodes because you don’t have to worry about Taxonomy Access Control - you can just enable / disable access per user role for an individual panel page.

      • Panel pages can be added to the Drupal menu system just like nodes

    • If you go this route, you’ll be using the Page Manager which provides a UI and API to manage pages within the site (ships with Chaos Tool Suite, aka ctools).

    • Probably used for standardized pages

  3. Panelized content types, with the option to panelize individual nodes

    • Use your existing content types and their defined fields (which are easier for your basic content editor to continue creating content)

    • Use the panels interface to determine where the fields are placed on the page

    • When necessary, you may “panelize” an individual node when it needs to break away from the style or layout that the other nodes use (of the same content type)

    • Or even better, utilize variants to create standardized variations of layouts or style for a particular content type. Consistency is good!

    • Panelizer also offers the ability to use panels for other view modes, such as the teaser view of a node, how it appears in search results, views, or any other custom display mode you might need.

    • Differences between Default, Full Page Override and Full Content displays

  4. Are there more Panels add-ons I should know about?
    1. Panels In-Place Editor (ships with Panels)
      1. Provides a UI for managing some Panels directly on the frontend, instead of having to use the backend.

      2. This is especially useful when Panelizing nodes, where you may want the flexibility to freely move panes around the page and play with the layout.

      3. Works with workbench moderation

    2. Mini-Panels (ships with Panels)
      1. Mini panels are small content areas exposed as blocks, for when you need to have complex block layouts or layouts within layouts.

      2. Mini panels can be used as blocks by traditional Drupal pages or as panes by other panel pages. You can even have mini-panels within mini-panels (not that this is a good idea).

      3. These are especially useful for moving around groups of sidebar content to reuse across various content types.

    3. Panels Everywhere

      1. Intended to be a replacement for your theme's page templates (page.tpl.php) in the same way that Panels can be a complete replacement for your site's node templates (node.tpl.php).

      2. The difference between Panels and Panels Everywhere is that PE is "aware" of page elements (like menus) that are not visible to Panels or node templates

      3. More on Panels Everywhere
    4. Classy Panel Styles

      1. CPS allows themers and designers to create groups of ready-made styles for site builders to choose from when laying out their pages. These translate directly to template and class changes in the DOM in a predictable way.

      2. It allows page builders to apply ready-made styles straight from the Styleguide — without having to remember class names!

      3. You may add classes on individuals components (panes: blocks, views, fieldable panels panes, node references.. etc) or on regions (bands)

    5. Panels Theme Override Module

    6. Fieldable Panels Panes

      1. This module creates an entity that may be used in panel panes to create fieldable entity panes. These panes can be created either directly in the Panels UI or in a separate administrative UI and later added.

      2. Once added, they can appear in the "Add content" dialog to be easily reused. Since they are fieldable entities, they can contain any kind of data that field API can provide.

      3. Each entity supports revisions, and any revision can be made current without having to make a new revision.

      4. FPPs can be translated

      5. You can create the various types of FPPs by using the FPP Bundles module.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.