regression in 5.8 from 5.7 theme('blocks','all') broken - so no header alteration possible

Both theme.inc and phptemplate.engine relied on the side effect of preloading all block content in the first call to block_list(), in order for drupal_add_js() and drupal_add_css() to be called before the page variables are set.

The performance fix was intended to avoid preloading the sidebars when they are not going to be rendered, but to avoid the regression all other regions need to be rendered early either way. For now at least, maybe block_list() should preload all content except 'left' and 'right', until those regions are specifically requested? phptemplate.engine seems to call theme('blocks', 'footer') early enough to cause the preloading even if $show_blocks is false so the sidebars are not rendered.

Alternatively, modifiying _phptemplate_default_variables to set the variables after loading all block content may work, but could cause regressions elsewhere.

Hey, thanks for the patch - I tried testing it, but it contains a call to 'array_fill_keys' which is only available to PHP 5 >= 5.2.0 (http://php.oregonstate.edu/manual/en/function.array-fill-keys.php)

Edit:
Tested the patch (adding a custom array_fill_keys function) and it fixes my problem of a CSS file not loading.

This seems to be related to this: http://drupal.org/node/280919

yeah it is related, and fixed it for me

@schuyler1d, against which version of Drupal are these patches based on? I tried them in 5.8 and they succeed with offsets.

I'm having the same problems - a custom module doesn't load the css files called via drupal_add_css(). This happened after the update to Drupal 5.8.

So far I have probably repeated the steps everyone else has. I reverted just the modules/block to the 5.7 version - it started to work again.

Looking at the patch @ 7 it applies to themes/engines/phptemplate/phptemplate.engine which didn't change in the recent update to 5.8. Block module did change, are we patching the correct thing?

There were 9 changes in block.module, for me reverting the 7th and 8th changes causes the css file to be added as it should. These changes are in the block_list(region)

I'm not sure what the answer is, but I thought I'd post my findings here since doing various print_r(); in the changed code (changes 7&8 in block.module) didn't highlight any differences in the resulting block. It seems that the block is being called with the same module_invoke(); on line 693.

Drew

@schuyler1d, OK, thanks, I just confirmed your comment, both v2 and v3 patches apply cleanly. My bad. Sorry.

Applied patch in #13 to phptemplate.engine and so far so great.

Thank you for the updated patch - #13 works for me

Committed to 5.x with minor code style fixes.

Where do I download the committed fix?

@ 18,
The fix is committed, so it will appear in the next release.

You can either apply the patch in #13, or get the patched Drupal from CVS. Alternatively you can revert the block module to the previous 5.7 version and wait for drupal 5.9 to be released.

The patching method is the probably safest. Info on patching: http://drupal.org/patch/apply .

PS
Thanks for the patch schuyler1d, it works for me :)

D

Is there anyone here who can add a note about this issue to the release node (http://drupal.org/drupal-6.3)? This will seemingly cause some headaches until there is a new version out (I spun my wheels for half an hour before finding this info). Since this affects popular modules (like the admin_menu module), it makes sense to me that there should be some warning on the release node indicating that admins will need to apply this patch in some cases.

OK, version 5.9 has been released.

I'm using drupal 5.10 and had the same issue. I'm assuming if this was fixed in 5.9 it should have been fixed in 5.10 also. I've reverted to block.module 5.7 and it fixed the problem. Any ideas why this is not working in 5.10?

I'm not sure it is back Craig.

My 5.10 site has the css files added for modules, the same as it was in back in 5.9.
Double check that the update was applied.

a fresh 5.10 has the same problem for me

I also tried it in a fresh 5.10 installation with v.1.5 of dhtml menu and all is fine.

I think I stumbled across this post when searching for a fix to a problem I was having with collapsible fieldsets. I have found with anything over drupal 5.7 they don't seem to work. Upon closer examination reverting to block 5.7 doesn't totally fix the issue. Am I posting in the wrong string?

@craigdurling
You may have more luck with a new thread, but if this issue has the same symptoms as this thread then post here. If you do create a new thread at least link to it from this thread to make marking as a duplicate easier (if required in the future).

Some things to check…
What does your status page say?

Try a clean install by starting with new downloads of Drupal core & the contributed modules, incase you have got versions of them messed up somehow.
If the bug is still there you know it's not something you have done wrong. Try testing with the minimum modules you can use and install them slowly and retest. Let us know at what point it goes wrong.

On the broken site check the source to see if the .js and .css are being added in the head (and/or footer for some js). Check the paths are accessible from the browser incase the permissions or .htaccess are blocking any of the files or directories on the server.

Is the browser reporting any errors in its activity (e.g. couldn't load xxx.js file?)

You can also post info from the status page to help diagnose your problem. At the moment all we know is it's broken for you, but not for us. We don't even know if it is you css or js not loading.

--
Help us to help you

I believe the leaf and menu classes are a part of core. It's just the way it marks up menu lists. I don't use DHTML Menu, (I use admin menu) but I have the classes too.

When I had this issue I noticed certain modules css files were not loaded, but some were. If you are loosing ALL scripts and/or css then it may be something else. I don't know if it cold be related to jquery? Do you have jquery update installed & ticked (green) on the site status page?

Subscribing, as I've been getting reports of gmap blocks malfunctioning due to this.

This patch has caused a problem with panels 2, when creating a panels page with blocks disabled, the header/footer region (etc) blocks are now not shown. This is a change in behavior - in Drupal 5.8 and prior these blocks were displayed - just the sidebars were hidden. This seems to be distinct from the js issues mentioned above, but is definitely related to the patch in this issue.

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 - <a href="http://drupal.org/node/281042" title="http://drupal.org/node/281042" rel="nofollow">http://drupal.org/node/281042</a>)
        if (isset($variables['regions'])) {
          $normal_blocks = $variables['regions'][$region];
          $variables[$region] .= $normal_blocks;
        }
        else {
          $normal_blocks = theme('blocks', $region);
          $variables[$region] = $normal_blocks;
        }
      }

I am not sure there a simple way to revert to the previous behavior without also breaking the "no blocks on 404" patch functionality. I am also not sure what is preferable if we have to choose 1 functionality to break!

Any ideas?

pretty sure this has broken views slideshow as well #281156: Site upgrade to D5.8 kills my slideshow block. i'll take a look later this week.

There are 3 issues I see here:

DHTML Menu - conflicting reports
Panels 2 - Hides blocks, but header is not expected to be hidden. Will be handled in #308002: Header region disappears on panel pages with "no blocks" selected - change of behaviour due to core.
Views slideshow - might be fixed, will be handled in #281156: Site upgrade to D5.8 kills my slideshow block.

I am going to close this and would like to see further issues handled separately since there is a bit of confusion here. As always, please test with clean and recent versions of everything.