Conflict with context module

subscribing.

Tried my luck at a patch based on a solution provided here in the Context issue queue:

http://drupal.org/node/633778#comment-2702988

This basically check if Context module is present and if so retrieves the blocks made visible using Context.
This might be lacking some logic since my understanding of how context is working is still limited.
Hopefully this will provide a base for a solution.

This worked on my local test site using Drupal 6.16, Context-6.x-3.0-beta4, Zen-6.x-2.0-dev

It's just my second patch so if this needs to be fixed, please be kind ;)

changed status hoping to get some review on the submitted patch in #4.

Patch in #4 fixes this issue :)
Tested with Context 6.x-3.0-beta5 and Zen 6.x-2.x-dev.

Worked for me with Context 6.x-3.0-beta5 and Zen 6.x-2.x-beta1. Subscribing.

The patch in #4 does work, but it doesn't address the $classes variable which sets the column definition. Now it simply defaults to "two-sidebars" for all. I'm trying to figure out where I'd need to patch either my zen sub-theme or zen to make this work. Any ideas?

I don't experience that problem, @mshaver. All my sidebars work exactly as expected. Body classes are what they should be when they should be.

Taking a step back, though, I'm not sure this is the "right" permanent solution. Obviously we can't be testing for the presence of every module out there and adjusting our logic before it becomes completely unmaintainable. Unfortunately, I don't know a better way at present. I'd like to get @JohnAlbin's opinion on this (or that of another maintainer). I'm going to bump this back to "needs review". In the meantime, though, this gets the job done.

Speaking of which, good job on your second patch, @Antoine Lafontaine!

Hmm, can't figure out why my $classes isn't being altered then? @TravisCarden: I'm assuming you're using a sub-theme of zen then? I'm using Context 6.x-3.0-beta5 and Zen 6.x-2.x-dev.

@mshaver: Yes, I'm using a Zen sub-theme. Perhaps you can tell us more about your configuration to help us help you. I don't even know what kind of questions to ask you at present. You didn't modify Zen core or anything like that, did you?

All: I do see one bit of unexpected behavior since applying the above patch. On my blocks administration screen, all the region labels appear twice.

OK, I just tried this on a fresh Drupal 6.17 install and still get the same issue with the $classes defaulting to "two-sidebars". Here are the modules I installed to reproduce.

admin 6.x-2.0-beta3
context 6.x-3.0-beta5
ctools 6.x-1.6
jquery_ui 6.x-1.3

For the theme I copied STARTERKIT and renamed without touching anything code beyond the name.
zen 6.x-2.x-dev
also tried it with zen 6.x-2.0-beta1

I then applied patch in #4. Context blocks are showing up after applying the patch, but zen is always passing "two-sidebars" in the body class.

BTW, I can confirm the region labels appearing twice as well. Let me know if you can reproduce this?

OK, this was something stupid on my part! :) The "Admin" module provides a setting called "Always show empty theme regions.", which enables all regions all the time. This of course will set your classes to "two-sidebars" if you have two sidebars in your page template.

I didn't quite think this was as wide reaching as it is and would only be available when the context editor was enabled. Sorry about the confusion.

Subscribing.

This still needs work to resolve the matter of the patch causing all region labels to appear twice on the blocks administration screen.

subscribing

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

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);
        }

I re-rolled the patch with batje's change.

The region labels are not showing up twice for me.

Duh. Attaching the patch would have helped.

I think I was having additional problems due to #831400: "context-" added to classes and id's for blocks when logged in.
Either way, the duplicate region titles are now there, so CNW.

Okay, this makes a lot more sense, and it resolves the double region titles.

Patch in #22 works here.

Patch in #22 works for me as well!

Patch in #22 works for me as well, thanks

#22 works for me, too. (It solves the original conflict with Context and doesn't cause duplicate region labels on the Blocks administration screen.) Thank you, @tim.plunkett. If we can get maintainer review, the patch can probably be committed.

Note that this patch WILL NOT WORK with Context 6.x-2.0 since the function context_get_plugin does not exist. Applying this patch to Zen 6.x-2.0 while using Context 6.x-2.0 will cause a white screen for this theme.

Yeah, sites I'm working with are having the problem Robert describes.

changing from
if (module_exists("context")) {
to
if (function_exists("context_get_plugin")) {

might be a solution?

Or (drupal_get_installed_schema_version('modulename', TRUE) < {update_number})?

subscribing.

subscribing

subscribing

JohnAlbin, any thoughts on #29?

Adding module and version checks into theme_blocks doesn't seem like an elegant solution, but it doesn't seem like Context is going to change. As their code comments state, "It is the responsibility of any themes implementing theme_blocks() to take advantage of context block visibility on their own."

subscribing

subscribe

#22 doesn't work for me, neither for zen nor for subtheme. I'm using zen 2.0 and context 6.x-3.0-rc1

Edit:
After removing zen and uploading it again I applied the patch again and it worked. Weird.

Encountered this bug on a dev site today. Using Zen 6.x-2.0 and Context 6.x-3.0-rc1.

The patch in #22 fixed it and don't seem to cause any problems on my dev site.

Needs input from JohnAlbin re: #29

Same here,

the patch in #22 fixed my blocks visibility problem as well.

Thanks!

Tracking. I thought I was losing my mind! Thank for this patch. #22 worked for me when applied to the main zen theme; I did not need to alter my subtheme.

#22 worked for me as well.

#22 has worked to get the regions showing again. Still missing are the block editing links. IS it possible to add these back?

#43 - I have my block editing links when using this patch. Maybe it is a CSS issue? Check to see if the markup for them is in the page source, perhaps.

Patch #22 works for me running Context 3.0 and Zen 2.

I have my block editing links when using this patch.

Same for me.

Patch #22 works for me running Context 3.0 and Zen 2.

Confirmed here as well.

RTBC?

I believe the reason it was not yet marked RTBC is that it is not Context 2.x-safe. See #29.

Needs to be made Context 2.x-safe

Pity Context doesn't define an API version the way Views does. If Zen were a module, I'd factor out the context support into a separate include, but I'm not sure what the "right" way is in a theme.

Still, it would be better to have a separate function that returns whether context is enabled and the version, rather than doing the check inline as in #29, for two reasons:

1. We can then reuse it in any subtheme or custom preprocess hook
2. It's cleaner to change if the Context API changes again

Context 2.0 is no longer an officially supported version of the module, and the upgrade path to Context 3.x is supported. Given that this patch isn't even in yet, I don't think it falls on Zen to support backwards compatibility.

As the one who wrote the patch, I not comfortable with it being committed as-is. I wrote it to get it working for a client, not to set a precedence of Zen checking for the existence of every version of module that wants to modify the blocks, or worse, not checking at all.

I didn't know that they dropped support for Context 2, but what happens when Context 4 comes out, or the behavior of Context 3 changes?

I just filed #910220: Implement an API version function, this would be a step in the right direction.

I wrote it to get it working for a client, not to set a precedence of Zen checking for the existence of every version of module that wants to modify the blocks, or worse, not checking at all. - tim.plunkett

As eager as I am to get this issue resolved, I strongly agree with this sentiment.

subscribe

I've tried the patch above and a function found in another thread, but neither work for me.

I have Zen 6.x-2.0 and Context 6.x-3.x-dev.

Can anyone confirm they have resolved the issue with this combination of Zen/Context? Is there an alternative to Context anyone can recommend? I have a site close to completion that requires different menu blocks depending on which part of the site you're on, I thought Context looked ideal.

#55: #22 patch resolved my issue with Zen 6.x-2.0 and Context 6.x-3.0. You might want to do some troubleshooting to determine why the patch isn't working for you. Was it successfully applied? Does the code snippet appear in template.php? Do the blocks appear if you use a core theme like Garland?

If so, try some debugging. Try using the admin module to verify that the context is in fact active on the page in question. Try outputting some test text in that function in template.php. Etc.

Patch #22 worked for me with the latest zen and context but, on the 'two-sidebars' issue (see #13) : the "show empty regions" checkbox is in admin/build/context/settings (context settings page) also. You should uncheck this to get the patch to work.

Patch #22 worked for me as well, but then I happened to go to Site Configuration > Administration Theme and then all my blocks disappeared again. I didn't even change my admin theme, I just went to that settings page and when I navigated back to other parts of my site, my Context based blocks disappeared again.

I'm not a developer, so I'm afraid I'm of no real use other than to say that the problem may not be entirely solved.

Any thoughts?

From http://drupal.org/project/context, it shows that Context 6.x-2.0 is not the recommended release, but it is still supported. Whether they are actively applying bugfixes is a different matter (and doesn't really matter since many sites will continue to use Context 2).

Since Zen 2 doesn't work with either Context 2 or Context 3, I'm fine with committing a patch that only works with Context 3 since that's "half fixed". However the patch in #22 no longer applies. Also, the patch looks wrong to me; if context is enabled, then Zen's region.tpl is no longer used to wrap up all the blocks for a particular region.

I'll get back to this tonight.

Here's my attempt at a fix. It should work with both Context 2 and 3. Needs testing.

Also, I just posted a patch to Context that fixes this issue for all themes, not just for Zen. #633778: Conflict with themes implementing theme_blocks()

oops. Tim pointed out an obvious bug in IRC.

New patch.

The patch in #63 works on several different sites using context 3.

Works with and without #633778: Conflict with themes implementing theme_blocks(). Fantastic.

Thanks for the reviews!

Fixed.

Awesome! Thanks!

Can we get a 2.1 release with this patch? i feel like this should be treated as a critical issue.

How do I install this patch? Usually when I come across a problem like this the patch has been committed to a new version...

@mattsmith3: Applying patches. :)

Nevermind. Google and a little command line experience took care of it. I did not think it would be so easy! Loving linux more and more every day!

For any other newbs...
http://drupal.org/patch/apply

ssh in, wget the file, run the command on the link above.

if you are using drush make, you can just add

projects[zen][patch][] = "http://drupal.org/files/issues/634552-63-context-conflict.patch"

to your make file. if you are not using drush make, then find out how to use it, and wonder how could you live without it before ;)

#63 worked for me - great work - thanks !

Patch #63 works for me too, thanks!

subscribe

tested patch in #63

works for regions provided by Zen but doesn't work on any additional custom regions that you add in a subtheme.

edit: when using in conjunction with Context module it doesn't allow custom regions. Haven't tested with other modules that use theme_blocks()

update: #77 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

Patch in #63 worked for me.

Using:
Zen 6.x-2.0 (was previously unaltered)
Context 6.x-3.0

add this to your drush make file with D6:

projects[zen][patch][] = http://drupal.org/files/issues/634552-63-context-conflict.patch

#63 worked fine for me! Thanks!!

Drupal 6.20
Context 3.0

Subscribing.

#63 worked great for me.

Drupal 6.19
Context 3.0
Zen 2

worked great for me too.
thx and best regards from vienna forest
karl

it is closed, can we stop changing the component?

I changed the capitalization of the component from "PHP Code" to "PHP code" a couple months ago. I didn't realize it would cause all the existing issues to shift the next time someone commented on them. Sorry about the noise.

Sorry to necrobump this thread, but there's a related issue with zen_blocks over here: http://drupal.org/node/474530#comment-4797946

New block regions are always empty even after blocks are placed in them, commenting out zen_blocks fixes it. The release in question contains the patch from 63 so I thought you all might be interested.

did you make any changes to zen_blocks? check it against the 2.1 release.

also, check if any module is implementing theme_blocks.

grep '_blocks($region)' sites/all/modules/ -R

I'm using the 2.1 release of Zen and I am using Context which implements _blocks. See my bug here: http://drupal.org/node/1261348