I don't seem to be able to get the sitewide context condition to work.
If I set the Sitewide context as a condition, and check the 'always active' box my reaction, display block X does not happen. However if instead of sitewide I choose path as the condition, setting the path to '*' my reaction works perfectly.

Maybe I'm misunderstanding the "Sitewide" condition but I assume it means the reaction should happen regardless of where you are with in the site.

Comments

mrsimonelliott’s picture

I have seen what is happening now, not sure why though.

The condition Sitewide is only applying to my admin pages. Previously the block wasn't displaying at all because the region I had chosen didn't exist in my admin theme. Now I'm using the same theme for admin as frontend, my block which should be displaying sitewide is only showing on the admin pages.

yhahn’s picture

Status: Active » Postponed (maintainer needs more info)

Is this still occurring in the latest release?

dsayswhat’s picture

I'm seeing a similar issue:

I can see the sitewide context most places, but it seems to fail when I visit content type pages.

The front page also wouldn't show the sitewide context, and so on a hunch I demoted all my content from the front page, leaving it empty, and guess what - sitewide context shows.

The issue appears to be only on pages that involve content types in my site. I tried various things like devel-generated content versus content entered by hand, and cck types vs stock pages as offered by Drupal core...no difference.

I did one more look, and rendered the same view a couple of different ways - a page displaying as 'html table' showed the sitewide context just fine, but 'node' display loses it.

Hope this helps...

n3uronick’s picture

I have the same problem.

dsayswhat’s picture

I was able to test further - this issue does not show up on Garland, Cube, or various other themes I've tried.

In my setup, the sitewide context goes missing when using the Fusion theme ( or its subthemes ). Apparently they don't play well together.

The details are:

In the fusion_core base theme, the fusion_core_preprocess_node function calls theme('blocks') on lines 167 and 168. When commented, the sitewide context shows up as normal.

I tried to replicate the bug in a non-fusion theme, but wasn't able to make the sitewide context fail. My guess is that Context might be slightly fragile when paired with themes like Fusion that do a lot of stuff.

There's an open issue in the Fusion theme issue queue (http://drupal.org/node/865782), so a solution could be reached over there...

Is there any way to make Context more bulletproof so that this kind of interaction with themes isn't so troublesome? Can it be made to respect but override theme behaviors for the purpose of enforcing it's control of the block system? Maybe it could be an optional behavior...sort of a --force for context?

yhahn’s picture

Have you tried to reproduce this with Context beta7 and or the latest dev release? There should be some better handling of early calls to theme('blocks') in these releases.

paulocs’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Fixed

Do you still have problems with 7.x or 8.x?
As context 6.x is no longer supported, I will close it.
Please feel free to reopen it.

Thanks.

paulocs’s picture

paulocs’s picture

Status: Fixed » Closed (fixed)