Conflict with themes implementing theme_blocks()

I can confirm this. Blocks appear when using garland, but not zen.

the problem lies somewhere in the zen_blocks() function.

@mrfelton chances are that the fact that the zen_blocks() function exists *is* the problem. Context also implements theme_blocks(), which it uses to populate the block regions.

I made the zen people aware of this issue:
http://drupal.org/node/634552

For the record, this issue only exists with zen2.

Zen 6.x-2.x just implements theme_blocks as a way to add a region.tpl.php template like D7 has.

Subscribing. I'll have to spend some time on this to think of a good solution before Zen 6.x-2.0 is released.

The code above cause all blocks to disappear on my site. I'll need to dig in some more :(

If I am not mistaken, this bug has the exact same cause as #457512: i18n blocks creates conflicts with themes and modules that override the theme_blocks function

The problem is that both Context and Zen2 override the theme_blocks function. The i18n module does this as well, which caused conflicts with both Context and Zen2. The i18n project have a working patch where they use hook_preprocess_block instead, but I don't know how feasible that is for Context.

Thanks everyone for tracking this down. There isn't really a good entry point other than theme_blocks() to alter the core block visibility behavior, and so that is where context does its thing.

I'll keep thinking about clean ways to resolve this issue as well.

Thanks for the update. I would love to bump this up to critical. In may case it's stopping me from using Context & Features because I'm married to the zen theme at this point. Unfortunately, this issue falls in that gray area b/w a bug and modules simply not playing nice together. Bummer.

@cfab where are you finding function zen_blocks?

So glad someone found this issue before now as it was really causing us some grief! Thanks cfab!

It should be noted that the cfab's solution (#6) won't work with version 3.x of context. I don't have time to code up an alternative, but will try in a few days. In the meantime, I just commented out the zen_blocks() function to solve the problem.

Thanks.

Maybe this helps this issue?

http://www.alldrupalthemes.com/drupal-blog/want-your-theme-be-compatible...

Removing Zen's hook_block() causes several of Zen's regions to render un-themed.
Can anyone recommend a base theme that supports Context natively, that will also allow one to theme without worrying over browser inconsistencies and the like? (Tao, or Rubik etc.)

(Context 6.x-3.0-beta3)

Subscribing, greetings, Martijn

Hey guys,

I got this working with Zen 2.x and Context 6.x-3.0-beta4, after sitting down and looking how Context 3.0 does its thing. So far, it works perfectly, and doesn't leave out Zen's block themeing as mentioned above.

Going along with @cfab's solution, I was able to come up with the following zen subtheme function for your template.php file :

/* testing for compatibility with context */
function YOURTHEME_blocks($region, $show_blocks = NULL) {

    if (module_exists("context")){
      
      // Since Drupal 6 doesn't pass $show_blocks to theme_blocks, we manually call
      // theme('blocks', NULL, $show_blocks) so that this function can remember the
      // value on later calls.
      static $render_sidebars = TRUE;
      if (!is_null($show_blocks)) {
        $render_sidebars = $show_blocks;
      }
      
      // Bail if this region is disabled.
      //$disabled_regions = context_active_values('theme_regiontoggle');
      //if (!empty($disabled_regions) && in_array($region, $disabled_regions)) {
        //return '';
      //}

      // If zen_blocks was called with a NULL region, its likely we were just
      // setting the $render_sidebars static variable.
      if ($region) {
        $output = '';

		$plugin = context_get_plugin('reaction', 'block');
    
        // Add any content assigned to this region through drupal_set_content() calls.
        $output .= $plugin->execute($region);
    
        $elements['#children'] = $output;
        $elements['#region'] = $region;
    
        return $output ? theme('region', $elements) : '';
      }
    }
    else {
		return zen_blocks($region, $show_blocks);
	}
}

I am still working on figuring out how to bail if the region is disabled, as I haven't found a function yet that compares to "context_active_values" in Context 3.0, let me know what you guys think!

subscribe

@marshallbu - seems to be working for me. good job :)

great, good to hear. I still haven't found a replacement block of code for the active regions area, but I haven't noticed any performance draw backs just yet.

Subscribe

Subscribe

I tried the code that marshallbu posted, but it didn't work for me. I'm using zen 6.x-2.x and context 3.x beta-4.

Subscribing. Thanks

subscribing

subscribing

Just an FYI: we are seeing a similar issue with blocks not appearing using Hexagon/Canvas.

I put an issue in the Hex queue pointing here: #811152: Possible conflict with Context

@yhahn, could Context account for themes overriding theme_blocks converted into a template? The theme Bonobo mentions doesn't use a theme function for the override.

Just provide a preprocess function for blocks then the theme won't have to hard code any fixes since it'll be included automatically.

Hrm, scrap that. Just noticed context_blocks() needs to catch the whole output so it's not as simple as adding a preprocess function.

FYI: this approach worked for us with Hexagon.

That approach would only work for Hexagon since it supports mini plug-in's.

This is just an idea and it might be a really bad one but if Context could create two fake blocks and position them first and last for each region, it could create the wrapper needed for context. That way, there would be no need for overriding any theme function.

That would also mean a good amount of rewriting the context plug-in for handling blocks. Might not be worth the trouble.

Zen has a patch to resolve the issue on its side at #634552: Conflict with context module.

Subscribing.

Subscribing

Subscribing.
#19 works with Zen 2.x-dev and Context 6.x-3.0-beta5, thank you

Subscribing

To prevent Contexts that do not use the block reaction to throw a

Call to a member function execute() on a non-object in...

error in the #19 code

here is the 2 lines to fix

          // Add any content assigned to this region through drupal_set_content() calls.
        if (is_object($plugin)) {
          $output .= $plugin->execute($region);
        }

Subscribing.

#634552: Conflict with context module

I'm actually working on a patch for Zen 2 that will fix the incompatibility with Context 6.x-2.0 and Context 6.x-3.0.

However, I thought of a way that context may be able to avoid the problem of it not wanting to override theme_blocks() when a theme also overrides it.

In context_page_alter() (context's preprocess_page function), it can go through all the regions and set the blocks with drupal_set_content(). Here's a totally untested patch.

Tim Plunkett tested the patch and noticed a typo in the patch. Here's an updated patch.

This is an elegant solution to a very common issue. No more will Context be a burden on themers!

Genius! Thank you, John!

Using patch in comment #45 with a zen sub-theme and Context-3.0, blocks added through the normal blocks admin page are added to each region twice, as duplicates.

Someone else reported this in IRC. I didn't see that when I tested it, but I'm going to get to the bottom of this!

If the variable context_reaction_block_disable_core is not TRUE, context_reaction_block's ->execute() will include core blocks, printing them twice.

Not sure what to do about that, but I'll get back to it tomorrow.

subscribe.

Thank you marshallbu for #19. This may not "fix" the problem but it got me back on track with two theme projects I has almost finished. Thanks so much for your time that you put into making this work. It is appreciated marshallbu.

Subscribe

Yes, Zen now implements a similar solution.
However, the goal of this thread is for Context to now longer require themers to provide Context-specific workarounds. Trust me, it's been a huge barrier for entry among new themers when convincing them to use Context.

subscribing

The solution from #54 does not work with Zen 2.x, use the code from comment #19

Subscribing

Was banging my head against the desk trying to understand Context for the first time. Just used the solution in #19 on Zen 6.x-2.0 using Context 6.x-3.0 and it worked great. Good to know that it was the theme and not my misunderstanding of the module.

subscribing

@daniel-san, it IS a bug on Context, but themes can workaround it (like the patch on Zen).

#19 works for the default zen regions but doesn't work for me on additional regions added in a subtheme

update: #64 nevermind, I was missing something obvious

I hadn't declared the regions in the context layout section on the .info file layouts[CONTEXTLAYOUTNAME][regions][] = REGIONNAME

I'm having the same problem with my Rocketthemes theme, and I tried the fix in #54, but came up with this error:

Fatal error: Cannot redeclare nexus_blocks() (previously declared in ...

Is there something I missed, such as where to put this code?

Thanks.

Yes, you redeclared a function, which means there is a nexus_blocks() function already. Search for it and use it.

I haven't used Zen in a while, and was banging my head on the desk until marshallbu's help on #19. Thanks! Luckily I don't need to add any new regions... yet.

"#19 works for the default zen regions but doesn't work for me on additional regions added in a subtheme"

#19 for me works also on added new region (with Zen 6.x-2.0 and Context 6.x-3.0). I generate subthemes in zenophile and add new sidbar, for now all context blok is visible.

Thanks for solution to my problem!

subscribe

Just to confirm that #19 works with Drupal 6.20, Context 6.x-3.0, Zen 6.x-2.0 and a subtheme of Zen. Thank you, marshallbu and tahiticlic!

#54 version looked nicer in terms of amount of code, but did not work as expected. There were signs of Context actually appearing in regions.

In regards to #69's issue - #19 also works with subtheme's additionally defined regions for me.

I'm wondering if it would be possible to have a small note added to the project's page (or readme or elsewhere) to warn users of this issue with Zen and other similar themes until the issue is resolved?

subscribe

thx everybody, worked great for me!

Zen 6.x-2.1 has been out for a while and has a work-around for this Context bug. You don't need to patch Zen to have it work with Context. And the problem doesn't exist in Zen 7.x-3.x since it no longer needs to implement theme_blocks().

This issue is borderline critical, but I'll leave it at major since only one feature is completely broken.

Added issue summary.

This should fix the bug described by Jethro and Tim in #48/50 above. Patch is untested.

Looks like Context 7.x-3.x won't need this since it's no longer overriding theme_blocks().

Clarified why Zen 6.x-2.0 was used to test the patch.

#75 is working fine for me, but i'm not totally across the bug that it was created to address. Not seeing any duplicates, but I didn't try the older patch either.

one of my views blocks went missing until I cleared the site cache today, could be related to this patch but I'm not sure.. will wait to see what other people say.

#75 worked for me as well.

I applied the patch incorrectly the first time which missed the update for plugins/context_reaction_block.inc. I was experiencing the duplicate block issue until I reverted and applied the patch correctly with git apply -v [patch-name.patch].

#75 worked for me. Block wasn't showing up, applied patch, block showed up. RTBC-ing since I'm basically the third reviewer.

#75 worked for for me with no issues. My sitewide context for blocks in a custom region is finally working immediately after applying the patch.

#75 still works (last stable). Make #916194: Block regions missing from admin/build/block as a duplicated of this issue.

Added note about new patch in #75.

Thanks to everyone for the work on this issue. Closing as outdated as this is for Drupal 6.