Forgive me if this is covered somewhere, I've been looking and haven't found it.

I think there is an incompatibility with either Panels or Zen Panels, and the 5.10 Drupal update. After making the update phptemplate engine would not show the header region content on any panel page which with a defined URL. The header block content appeared on panel override pages (e.g. node/%). Downgrading phptemplate.engine to the one released with Drupal 5.8 resolves the problem. I think it may be to do with the changes in 5.10 about the order which blocks are loaded in, but I'm not an expert.

CommentFileSizeAuthor
#3 308002.patch620 bytesowen barton

Comments

Czymra’s picture

Not sure at all if this is related but my custom regions seem to conflict with the panels 'header' region. I however use the Panel Module. Sorry if this is is unrelated.
I'm on 5.10 as well.

Error messages:

warning: Cannot modify header information - headers already sent by (output started at /usr/local/psa/home/vhosts/url/httpdocs/drupal5/sites/all/themes/symposium/template.php:3) in /usr/local/psa/home/vhosts/url/httpdocs/drupal5/includes/common.inc on line 141.
warning: Cannot modify header information - headers already sent by (output started at /usr/local/psa/home/vhostsurl/httpdocs/drupal5/sites/all/themes/symposium/template.php:3) in /usr/local/psa/home/vhosts/url/httpdocs/drupal5/includes/common.inc on line 141.

owen barton’s picture

Tracked this down to http://drupal.org/node/281042
Probably will patch there, but I am leaving this open for others (or in case that issue is somehow the correct behavior).

owen barton’s picture

Title: Header region disappears on some panel pages » Header region disappears on panel pages with "no blocks" selected - change of behaviour due to core
Status: Active » Needs review
StatusFileSize
new620 bytes

I tracked this down to the following code (broken out for readability) in phptemplate.engine:

      if (!in_array($region, array('left', 'right', 'footer'))) {
        // Working code (5.8)
        if (isset($variables[$region])) {
          $variables[$region] .= theme('blocks', $region);
        }
        else {
          $variables[$region] = theme('blocks', $region);
        }
        // Non-working code (5.10 - http://drupal.org/node/281042)
        if (isset($variables['regions'])) {
          $normal_blocks = $variables['regions'][$region];
          $variables[$region] .= $normal_blocks;
        }
        else {
          $normal_blocks = theme('blocks', $region);
          $variables[$region] = $normal_blocks;
        }
      }

There doesn't seem to be a simple way of reverting this code, without also reverting the original issue (which is that blocks were being generated on 404 pages, a significant performance issue).

In addition, it could be argued that this is the expected behavior from panels point of view, because the description on the checkbox is "'Check this to have the panel page disable all regions displayed in the theme.'", which suggests that header and other regions will indeed be empty of configured blocks. However this is a change of behavior, since in Drupal 5.8 (and prior) the blocks were always displayed in these regions.

Either this needs to be fixed in core (which seems a little unlikely now, perhaps - unless other problems are found), or needs to be fixed in panels.

This could be done simply by allowing the page theme to load the blocks (see attached patch). This leads to a bit of redundancy because the sidebars are generated but never shown (AFAICS). There is probably a more elegant solution out there though.

Ideally it might be nice to make this panels control a radio to allow you to leave blocks as is, disable just the left/right region blocks, or disable *all* region blocks.

sdboyer’s picture

Assigned: Unassigned » sdboyer

slating for my work time this weekend

drumm’s picture

Project: Panels » Drupal core
Version: 5.x-2.x-dev » 5.x-dev
Component: Panel pages » theme system
Status: Needs review » Active

This patch doesn't make sense, there is no second argument to theme('page') in Drupal 5, so the FALSE goes nowhere.

Since this is a behavior change, then it can be fixed in Drupal 5.x. This issue should be used so we can keep this specific issue separated out.

owen barton’s picture

I am not quite sure where this was fixed, or how - but as of 5.14 and the latest panels 2 I can no longer reproduce this. Is anyone else still able to?

dpearcefl’s picture

Status: Active » Closed (won't fix)

Considering the time elapsed between now and the last comment plus the fact that D5 is no longer supported, I am closing this ticket.