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?

CommentFileSizeAuthor
#22 657710-context_respect-i18nblocks.patch6.48 KBafox
#12 block-settings.png174.46 KBjbomb
#12 context.png154.17 KBjbomb
#2 657710-context-respect-block-language.patch931 bytesmrfelton

Comments

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

#402150: Conflict with i18n block translation: Context defined blocks don't show up
#632322: Context language condition support

mrfelton’s picture

mrfelton commented
StatusFileSize
new 657710-context-respect-block-language.patch931 bytes

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.

mrfelton’s picture

mrfelton commented
Status: Active » Needs review
kle’s picture

kle commented

subscribing

kle’s picture

kle commented

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...

svendecabooter’s picture

svendecabooter
he/him
Primary language Dutch
Location Gent
commented
Status: Needs review » Reviewed & tested by the community

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.

steven jones’s picture

steven jones commented
Status: Reviewed & tested by the community » Closed (duplicate)

Looks like this got fixed in the i18nblocks module: #457512: i18n blocks creates conflicts with themes and modules that override the theme_blocks function.

NaX’s picture

NaX commented
Version: 6.x-2.0-beta7 » 6.x-2.0
Status: Closed (duplicate) » Needs review

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.

danny_joris’s picture

danny_joris commented

#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?

jax’s picture

jax commented

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.

jmseigneur’s picture

jmseigneur commented

Subscribing

jbomb’s picture

jbomb commented
Title: Block visibility by language selection (i18nblocks) is not respected » Context block reactions override core block visibility settings.
Version: 6.x-2.0 » 6.x-3.x-dev
StatusFileSize
new context.png154.17 KB
new block-settings.png174.46 KB

I am experiencing the same problem with block visibility settings and context. I've included a description of my installation below

Name Installed version Proposed version Status
Admin 6.x-2.0 6.x-2.0 Up to date
Drupal core 6.19 6.19 Up to date
Boxes 6.x-1.0 6.x-1.0 Up to date
Context 6.x-3.x-dev 6.x-3.0 Up to date (Nov. 5, 2010).
Ctools 6.x-1.8 6.x-1.8 Up to date
Features 6.x-1.0 6.x-1.0 Up to date

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.

jbomb’s picture

jbomb commented
Title: Context block reactions override core block visibility settings. » Block visibility by language selection (i18nblocks) is not respected
Version: 6.x-3.x-dev » 6.x-2.0

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.

steven jones’s picture

steven jones commented
Assigned: Unassigned » steven jones
Status: Needs review » Needs work
wanjee’s picture

wanjee commented

subscribing

BarisW’s picture

BarisW commented

Subscribing, this is a must-have for context..

botris’s picture

botris
Primary language Dutch
Location Creuse, France
commented

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...

hedac’s picture

hedac commented

I'm having the same problem... i18nblocks options not being respected.
i18nblocks 6.x-1.9 context 6.x-3.0

steinmb’s picture

steinmb commented
Version: 6.x-2.0 » 6.x-3.x-dev
Status: Needs work » Active

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.

thomas.feichter’s picture

thomas.feichter commented

subscribing

afox’s picture

afox commented
Project: Context » Context Respect
Version: 6.x-3.x-dev » 6.x-1.x-dev
Assigned: steven jones » Unassigned

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.

afox’s picture

afox commented
Assigned: Unassigned » afox
Status: Active » Needs review
StatusFileSize
new 657710-context_respect-i18nblocks.patch6.48 KB

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.

kevinquillen’s picture

kevinquillen commented
Assigned: afox » kevinquillen

I want to get this patch into dev for testing, but I am having trouble getting ahold of the 6.x-1.x branch. It might not even exist. I'll need to figure that out then I can get this patch in to be tested.

steinmb’s picture

steinmb commented

git -r list all remote branches, and no it's not there though git ls-remote show the tags list so you prob. could checkout by using the ver 6.x-1.1 sha key.

kevinquillen’s picture

kevinquillen commented

I think I got it. Check the new dev version later it should have the changes in it.

kevinquillen’s picture

kevinquillen commented

Yeah, looks like the dev updated.

gagarine’s picture

gagarine commented

I opened the same bug in i18n for D7 #1838610: Menu block language visibility do not work with context

frob’s picture

frob
Primary language English
commented
Status: Needs review » Postponed (maintainer needs more info)

Is this still an issue with the latest dev applied?

kevinquillen’s picture

kevinquillen commented
Status: Postponed (maintainer needs more info) » Closed (outdated)