| Project: | Context Respect |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | afox |
| Status: | needs review |
Issue Summary
Steps to reproduce:
On a site with 2 or more languages enabled... (for the example I'll use EN and IE as the two languages)
1) Create a new block
- set the language to IE
- set the title to 'IE block'
- set the content to 'ie test content'
1) Create another new block
- set the language to EN
- set the title to 'EN block'
- set the content to 'en test content'
3) Position both blocks on the same page using the standard blocks interface (not context).
- Visit the page at /ie/test-page and verify that only the IE block shows
- Visit the page at /en/test-page and verify that only the EN block shows
(This is correct behaviour)
4) Remove the blocks
5) Create a new context and use it to place both of the blocks in a region.
- Visit the page at /ie/test-page:
now, you will see both blocks, but only the IE block has a title
- Visit the page at /en/test-page:
again, you will see both blocks, but only the EN block has a title this time.
I managed to trace the problem to this section of code in context.core.inc in context_block_list()
// It's possible that there are still some leftover blocks in the enabled contexts.
// Add these in as well.
if (!empty($context_blocks)) {
foreach ($context_blocks as $block) {
$block = (object) $block;
$block->status = 1;
$block->enabled = TRUE;
$block->page_match = TRUE;
$block->throttle = FALSE;
$block->title = '';
$blocks[$block->region]["{$block->module}_{$block->delta}"] = $block;
}
}Remove that chunk of code and the language sensitive blocks function perfectly (as per serp 3 above).
So, why is that chunk of code there? And, if it is really needed, how can we make it not screw up the language sensitive blocks like it does currently?
Comments
#1
#402150: Conflict with i18n block translation: Context defined blocks don't show up
#632322: Context language condition support
#2
Attached is a patch that removes the offending code for those affected. Perhaps not a final solution, but it's been working perfectly for me, though there may be some use case that I am unaware of that requires this additional code.
#3
#4
subscribing
#5
OK - Context doesn't recognize the blocks language setting in a proper way...
My workaround: Instead of using these settings I set the Block to Language neutral and add some PHP in the Show-Block section:
<?php global $language; return($language->language=="en"); ?>"de" <-> german ...
Works like expected...
#6
Patch in #2 works perfectly on multiple testing sites.
I applied it together with the patch in http://drupal.org/node/457512#comment-2352474 to fix the registry_alter conflict between context & i18nblocks module.
#7
Looks like this got fixed in the i18nblocks module: #457512: i18n blocks creates conflicts with themes and modules that override the theme_blocks function.
#8
I am currently working on a site with 6 languages and I have just run into this same problem and the #2 patch seem to work for me.
I am going to do more testing to confirm.
I am running i18n 6.x-1.5 and Context 6.x-2.0.
From what I can tell the bug mentioned in #7 only solved part of the problem (committed since i18n 6.x-1.4 release).
Can anybody confirm if the code suggested for removal is required for anything.
#9
#2 nor #5 is working for me using 6.x-3.0. Odd.
I really wonder why it wouldn't work for me. Any ideas?
#10
patch in #2 is currently working for me but that code is there for a reason
Update: I created a new views block and added it through context but it didn't show up. Resetting the code made it show up. So the patch no longer works for me.
The same issue exists with #934484: Respect domain_blocks settings.
#11
Subscribing
#12
I am experiencing the same problem with block visibility settings and context. I've included a description of my installation below
The block reactions for the my sitewide context will always display all blocks regardless of the visibility settings set within the block administrator. This is easily reproduced by adding a block that should not be displayed on any page to a context.
#13
Looks like the issue that I described here was considered "by design" in #550934: Block visibility by role is not respected.. Reverting to previous title and version.
#14
#15
subscribing
#16
Subscribing, this is a must-have for context..
#17
Subscribing.
Right now I have many contexts, discovering menu are shown for each language, forces me to copy each context for each language. A lot off work...
#18
I'm having the same problem... i18nblocks options not being respected.
i18nblocks 6.x-1.9 context 6.x-3.0
#19
Also see this odd behavior. Have not had time to dwell deeply into the issue yet, but still there. Bumping this up do latest 6.x code version, 2.x is dead.
#20
subscribing
#21
This issue would be better dealt in a separate module, like http://drupal.org/project/context_respect. Context Respect already enables context to respect other block settings, so that would be a more logical place for this issue also.
Issue #1108566: Extend to support i18nblocks was already created for it. Marking that issue as duplicate and transferring this one to the context respect queue as this issue is older.
#22
Well, it was actually quite easy with Context respect. Here's a patch which includes the i18nblocks support and a little modification to make future implementations easier. Initial testing made on couple sites and seems to work.