Blocks: theme('blocks', 'REGIONNAME') fails when called in template_preprocess_node

I have the same problem. I am using Context 6.x-2.0 though, but almost the same exact thing is going on. In my case it is the default condition (I think this is only an option in the 2.0 version right now) that fails when theme('blocks', 'regionname') is called. Sitewide and other conditions work, but I need the default condition.

I also need the block region in node.tpl.php. Wondering if there's a workaround?

This is because Context is doing a hook_theme_registry_alter to control blocks. In that hook in context.core.inc, there is a comment that basically you have to deal with it on your own:

  // Reroute theme_blocks() through context_blocks to determine block
  // visibility by context. Only override theme_blocks() if a theme
  // has not overridden it. It is the responsibility of any themes
  // implementing theme_blocks() to take advantage of context block
  // visibility on their own.

So basically you need to pull some of Context's code into your theme. Once I figure out exactly what needs to be done I'll post back. We should also get this documented somewhere that people would actually find it, especially if they aren't the type who can dig into the module code to find out what the real problem is.

This occurs because theme('node') is often called too early in the page generation stack for all context conditions to have run.

I'm not sure I'll be able to address this problem but it's on my list.

I too encountered this (3.x-dev), however, from context inspector it looks like the sitewide context isn't active after calling theme('blocks', 'REGIONNAME') from template_preprocess_node while my node-type conditioned context is. Removing the call to theme('blocks', 'REGIONNAME') from template_preprocess_node makes them both active.

Assuming you didn't mean to blow away these changes : )

This should be fixed with http://drupal.org/cvs?commit=399958.

Note that some conditions fire too late (sitewide condition, menu trail condition in particular) to be used in conjunction with a context that provides blocks in a node template region. Other conditions, like the node type or path conditions, should work.

Hi there -

I'm using the context 3.0 release, which should incorporate the patch above, no? Your notes mentioned that '...Other conditions, like the node type or path conditions, should work...'

My context uses a node type condition, places a block, and works normally in the typical use-case. However, I'm encountering the same issue as described above.

However, preprocess_node is unable to pull the content in using theme('blocks', 'region') or context_blocks('region').

In fact, doing so wipes out the context. I've echoed the region it in the page.tpl.php file to doublecheck things, as well as attempting to include it in my node.tpl.php...and it blanks the content of that region out when the preprocess_node function touches theme('blocks') or context_blocks(). Commenting the line makes it work again.

After dumping variables at a variety of places, it appears my template_preprocess_node is getting called BEFORE context runs - that's probably normal, but under the conditions you describe, I thought a note-type condition might work. Seems it doesn't.

In the short term ( deadlines loom, after all ), what tips can you offer about the comment reading :

  // It is the responsibility of any themes
  // implementing theme_blocks() to take advantage of context block
  // visibility on their own.

I tried to use various pieces of context in my preprocess function without success - calling in context_blocks, and some of the bits that it calls. However, I was unsuccessful, and I'm at a loss as how to proceed...so how would you recommend I take advantage of context block visibility?

Are there any ways to work around this, or any way I can help troubleshoot, further info I can provide?

Thanks for the great module...and for supporting all our edge cases.

Re #6: Based on our recent experience on a project, I'm assuming that "context" conditions also fire off too late for this to work properly. Can anyone confirm this? In our case the context condition referred to a context that only uses "path" as a condition.

subscribe

We found our solution by stripping the context condition (or condition of type context) out of the contexts altogether. Then adding this bit of code to work that condition by hand so to speak:

/**
* Preprocessor for nodes.
*/
function [module_name]_preprocess_node(&$vars) {

if (context_get('context', 'alpha')) {
context_set('context', 'beta', new stdClass());
}
else {
context_set('context', 'gamma', new stdClass());
}

}

So we're essentially making the 'beta' and 'gamma' contexts active in the same places, then checking to see if the 'alpha' context is active to decide which one should be DEactivated. Kind of doing things in reverse. Make sure to deactivate the contexts by setting them to new stdClass() or you'll get PHP errors of the "can't access property from non-object" variety. You could probably use context_del('context', 'xxx'); but be sure to test thoroughly there.

Hope that makes sense. ;)

Hi add1sun, I'm just asking that on another thread. Did you find the way to do it?

Is this an issue also in Drupal 7..?
Because it seems i cannot get the region in a node to be filled with blocks basing on a context.
Thanks,
Da.