Problem/Motivation

Being Panels-based, Panopoly excels at custom page layouts. It doesn't include support for placing blocks into theme regions. This lack raises some challenges, like:

  • On initial install of Panopoly, no system help appears on e.g. the admin/modules page, as the help block is not displayed in the help region.
  • If you're using a theme that requires the main menu's block to be displayed in a menu region, or that's incomplete without some bottom of page content like a menu, you're on your own.
  • It's difficult to display consistent site-wide elements - e.g., a sitewide login block - in the main page area since that area is controlled by many distinct panels pages.

These are the sorts of tasks that some distros have used Context for, or programmatic enabling of blocks, but any such block placement would seem at odds with Panopoly's pure Panels approach.

So probably the question here is not so much how to place blocks into theme regions in Panopoly but rather how to define some common approaches that Panopoly based sites and distros can use.

Proposed resolution

Some possible approaches:

  • Site admins can manually assign blocks using Drupal core's block admin page.
  • On distro install, programmatically enable and assign to theme regions any required blocks, e.g., the system help block.
  • Use Context for block placement in theme regions outside the main page area.
  • Come up with a way for Panels to assign panes to theme regions. See #680064: Control theme regions.
  • Use Panels Everywhere.

See also this related issue #1557842: Allow Feature module exports to add Panes to Existing Panels, which includes discussion of the problem of how to implement sitewide elements using Panels.

Remaining tasks

Original report by nedjo

I recently cribbed from Panopoly to add theme selection to the Open Outreach distro, #1638128: Provide theme selection screen at install time. One thing I couldn't figure out was how Panopoly assigns the help, main content, and main menu blocks to their respective regions. I ended up putting some awkward code in Open Outreach to handle this (copied below).

Quick hint as to where to look for this in Panopoly?


  // Assign regions for the theme.
  // TODO: how does Panopoly automate this?
  $regions = system_region_list($theme);
  $blocks = array();

  $assignments = array(
    'system' => array(
      'main' => 'content',
      'main-menu' => 'main_menu',
      'help' => 'help',
    ),
  );

  foreach ($assignments as $module => $module_blocks) {
    foreach ($module_blocks as $delta => $region) {
      if (isset($regions[$region])) {
        $blocks[] = array(
          'module' => $module,
          'delta' => $delta,
          'theme' => $theme,
          'status' => 1,
          'weight' => 0,
          'region' => $region,
          'pages' => '',
          'cache' => -1,
        );
      }
    }
  }
  if ($blocks) {
    foreach ($blocks as $record) {
      $query = db_merge('block')
        ->key(array('theme' => $record['theme'], 'module' => $record['module'], 'delta' => $record['delta']))

        ->fields($record)
        ->execute();
    }
  }

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
CreditAttribution: nedjo commented
Title: How does Panopoly assign » How does Panopoly assign content, main menu, and help blocks?
populist’s picture

populist CreditAttribution: populist commented
Status: Active » Closed (works as designed)

Outside of some integration with the FacetAPI blocks as part of Panopoly Search, Panopoly doesn't use blocks :)

nedjo’s picture

nedjo
he/him/his
Primary language English
CreditAttribution: nedjo commented

Thanks for the note. I see you're not using blocks. What I haven't quite grasped is, how are you assigning content to non-panels regions? E.g., how is the sitewide menu assigned to the theme's main menu region?

nedjo’s picture

nedjo
he/him/his
Primary language English
CreditAttribution: nedjo commented
Issue summary: View changes

Fix error in sample code.

nedjo’s picture

nedjo
he/him/his
Primary language English
CreditAttribution: nedjo commented
Title: How does Panopoly assign content, main menu, and help blocks? » Define best practices for block placement in Pantheon-based distros or sites

I was forgetting that core themes don't require a menu block.

Anyway, repurposing this issue a bit to try to define some best practices for block placement in Pantheon based distros or sites. I know, part of the point of Pantheon is not to have to worry about blocks, but there seem to be a few cases where we can't, yet, do without them, or some equivalent.

I've updated the issue summary with some possible approaches. Additional ideas? Which of these fit best with Panopoly's approach?

nedjo’s picture

nedjo
he/him/his
Primary language English
CreditAttribution: nedjo commented
Category: support » task
Status: Closed (works as designed) » Active

I'm looking into whether I could rework the Open Outreach distro to build on Panopoly and the questions outlined in this issue are some of the key things I need to work through.

See #1664956: Make Open Outreach Panopoly-based.

@populist: any ideas you can pitch in to this and #1664956 would be very appreciated.

populist’s picture

populist CreditAttribution: populist commented
Status: Active » Closed (duplicate)

Thanks much for posting this and I think we have a pretty good start to addressing this through documentation #1713516: Provide Documentation on How to Use Panopoly as a Base Distribution and sidebar discussion #1713524: Mini Panels + the Sidebar Problem, as well as some specific comments for Open Outreach #1664956: Make Open Outreach Panopoly-based. I am going to close this specific issue in lieu of the others, but certainly want to keep chatting.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented
Title: Define best practices for block placement in Pantheon-based distros or sites » Define best practices for block placement in Panopoly-based distros or sites
Component: Code » Documentation
Category: task » support
Status: Closed (duplicate) » Active

I know this issue is marked as closed and there is lots of great stuff linked to in the conclusion but I still don't have a handle on the best practice for this.

Per the description:

Some possible approaches:

  • Site admins can manually assign blocks using Drupal core's block admin page.
  • On distro install, programmatically enable and assign to theme regions any required blocks, e.g., the system help block.
  • Use Context for block placement in theme regions outside the main page area.
  • Come up with a way for Panels to assign panes to theme regions. See #680064: Re-use theme regions.
  • Use Panels Everywhere.

Are there any distros that made one of those choices? What are the trade-offs? What does the Panopoly team see as the best/worst options?

My distro really only needs to put a couple things in the header and footer. I'm thinking programatically enabling the blocks in install seems like the simplest solution (at least with the default theme). But I want to work within best practices if there are any!

If there already is a document somewhere addressing this, I'd like to request that the link be made more prominent! I've been through the base distribution, site development and app writing documentation a few times and didn't see anything about this.

populist’s picture

populist CreditAttribution: populist commented
Status: Active » Fixed

Not to suggest I am an expert on how blocks are used, but my opinion is that the best practice is to define them in the .install file (similar to how drupal core does it for user login and navigation blocks) when they are going into theme regions and into an exported page manager page (when they are included as part of a page manager page).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) CreditAttribution: commented
Issue summary: View changes

Repurpose the issue.

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
CreditAttribution: hanoii commented
Category: Support request » Task
Status: Closed (fixed) » Active

Sorry to bring this one up again, but I have the feeling that this question is still valid. 2 years have gone by and I couldn't seem to find any definite recommended way of doing something like this, namely having an option to put panes on every page somehow?

Is there any real update on the recommended way of the proposed resolutions here are the usual options (enable blocks and work with both blocks and panel,s use context, etc.?) Bear in mind that I chose to try panoply to provide build a complex distribution for a company that I hope for them to make them simpler to do the site building. However, not having an easy way of adding panes to all of the pages is in a way limiting. Is there any update on this? I also think this deserves a handbook page as well. I am willing to do it if there's something to define.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented

A lot has changed since this issue was opened! (One of things you may notice is that back in comment #7, I was still a contributor asking this question and now I'm a maintainer answering it ;-))

So, it might make sense to open a fresh issue, because I'm not sure how to respond to a lot of the out-dated stuff in the issue summary. For example, we do now enable the block module and use it for system help. And it is now possible to add panes to an existing Panel via Features (using Features Override).

But I do agree that we should document the common ways this problem is solved!

I'll summarize the four most common here:

  1. Using blocks for site-wide header and footer. This is an approach that I personally use on most Panopoly sites. Usually, the header and footer are pretty static and don't need the power of Panels, so it's a very simple way to go without introducing too much complexity. However, blocks won't work for doing site-wide sidebars because it would conflict with Panels taking over the content region.
  2. Coding the site-wide header and footer directly in the theme's page template. This is the approach taken by Kalatheme. Again, with a relatively static header and footer, this can work great! It avoids the block system from approach #1, but requires editing code to make updates. Otherwise, very similar to #1!
  3. Using Mini-panels as reusable header, footer or sidebar content. This is a super common technique used in a couple distributions (for example Open Atrium). I personally like to use it for site-wide sidebars, creating a "Sidebar top" and "Sidebar bottom" mini-Panel that I add to any that Panel that has a sidebar. Open Atrium actually pulls in its "Header" and "Footer" mini-Panels in from the theme! So, they act like theme regions. I think this is a great approach - it's sort of like a "poor man's Panels Everywhere". :-)
  4. Using Panels Everywhere to take over the full page template. The obvious all Panels approach! However, it's actually not that commonly used. I'm not aware of any Panopoly-based distribution that uses Panels Everywhere out-of-the-box, and I personally have never used it on a real production Panopoly site. Although, I think it does have its use case! If the "chrome" parts of your site (ie. header, menu, breadcrumbs, footer, etc) are relatively static, then it's easier to just do them in the theme. But if you need to drastically change them for different pages or parts of the site, then Panels Everywhere is a wonderful solution and would be much cleaner than doing it in your theme.

I think approach #1 and #3 (or a combination of those two) are the most common.

Anyway, I'd love your help expanding on that and turning it into a handbook page!

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
CreditAttribution: hanoii commented

Thanks a lot @dsnopek! Just to be sure on something, all four solutions still require that you define a layout for each content type and each landing page. they are not really site-wide sidebars until I add the mini panel to each sidebar, right? Or am I understanding something wrong?

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented

@hanoii: That's how #3 works: you define some "Sidebar" mini-Panel and then add it to your content types via Panelizer. With #4, you wouldn't necessarily do it like that (although you could!) because you now have control over the whole page template, you could choose to do your sidebar in Panels Everywhere rather than in Panelizer.