i18n blocks creates conflicts with themes and modules that override the theme_blocks function

I'll be following on the Context module issue.

Hi Jose,

I don't see the needs of overriding "theme_blocks()" function. A "hook_preprocess_block()" could be enough.

If you agree this, I can build the patch.

Makara

Subscribing.

One solution would be to get rid of i18n block entirely, and use a single context per language instead...

#632322: Context language condition support

See also #644044: Activating module Block Translation breaks sidebar rendering in the Zen issue queue.

I built the patch, based on cvs DRUPAL-6--1.

I didn't change the code that does the translation, but just moved it from hook_theme_registry_alter() into hook_preprocess_block(). This solves the conflict.

Please review.

Thanks, your patch works great!

Patch works:
Updated i18n to dev version. Applied patch. Confirmed that theme_blocks is rendered correctly. Menus and blocks are still ok.
Thanks!

Updated i18n to dev version. Applied patch. Got this error:

Fatal error: Uncaught exception 'ReflectionException' with message 'Function i18nblocks_theme_blocks() does not exist' in /home/khaleej4/public_html/jobs/sites/all/modules/devel/devel_themer.module:389 Stack trace: #0 /home/khaleej4/public_html/jobs/sites/all/modules/devel/devel_themer.module(389): ReflectionFunction->__construct('i18nblocks_them...') #1 [internal function]: devel_themer_theme_twin('blocks', 'sidebar_first') #2 /home/khaleej4/public_html/jobs/sites/all/modules/devel/devel_themer.module(230): call_user_func_array('devel_themer_th...', Array) #3 [internal function]: devel_themer_catch_function('sidebar_first') #4 /home/khaleej4/public_html/jobs/includes/theme.inc(617): call_user_func_array('devel_themer_ca...', Array) #5 /home/khaleej4/public_html/jobs/includes/theme.inc(1774): theme('blocks', 'sidebar_first') #6 [internal function]: template_preprocess_page(Array, 'page') #7 /home/khaleej4/public_html/jobs/sites/all/modules/devel/devel_themer.module(451): call_user_func_array('template_prepro...', Array) # in /home/khaleej4/public_html/jobs/sites/all/modules/devel/devel_themer.module on line 389

Error disappears after disabling Theme developer 6.x-1.18 (D 6.14).

Also, menus and blocks are ok.

Well, obviously 'Function i18nblocks_theme_blocks() does not exist', since that is what this patch substituted for 'function i18nblocks_preprocess_block(&$variables)'. It looks like the error might be due to some leftover cache. Could you confirm whether your problem persists, after emptying caches?

I enabled Theme developer, and received no errors.

Success for me running that patch against the 6.x-1.2 release - blocks are now back in their place on my subtheme based on the Zen 6.x-2.0 beta 1 release. Thank you very much, makara!

Success for me. Great!

subscribing

The patch in #6 applies perfectly, and is probably the way this should have been implemented in the first place.
This fixes the conflict this module has with the Context module beautifully.

#6 patched.

Will test soon, great work.

Works for me, +1 to commit this.

I'd really like Zen 6.x-2.x to be compatible with i18n, but it won't be until this patch is committed. It has been RTBC for 2 months now.

Works perfectly for me.
+1

The check plain is causing html (a link) in the block title generated via menu_block module to become all not treated as html.

However, there's a comment "// Check plain here to allow module generated titles to keep any markup." that suggestions the html should be preserved by the check_plain, which doesn't quite make sense to me, so I'm thinking I'm not quite getting something.

edit: It appears to be a conflict between panels/ctools. Likely the check_plain is being run twice.

(Looked over the patch and realized the check_plain was a pre-existing condition, so moving back to RTBC, sorry :) ).

Adding my review, patch applied cleanly to i18n dev (2010-Jan-03) and works as expected, thank-you very much makara!

The patch looks good, though it needs updating for latest i18n/i18nstrings changes (6.x-1.3 security release).

Also the language condition is now supported by context which is a possible workaround, see #4

Re-rolled.

Since this breaks themes, I would still consider this issue a bug. But let's not let pedantic categorization get in the way of committing it. :-)

New patch applies cleanly to updated i18n. (I had to empty caches to see the result though)
Thanks. Let's get this committed.

Great!

Committed. Thanks.

I reopened the original context issue #402150: Conflict with i18n block translation: Context defined blocks don't show up because it doesn't work on D7.

From the issue in context: "Block managed with context can be translated (string translation) but the translation never show up, always the original content.

If you try to only show a block for a language (in the block settings) it doesn't work, the block is always visible."

I don't get why it doesn't work anymore perhaps it's an other issue now...

Yes, this is another issue.

Besides, i18n uses hook_block_view_alter() to do the block translation. If context doesn't run the blocks through that hook, or it loads the blocks differently to drupal core there's very little we can do.

OOhh! Am I reading this right? Context won't work with i18n?

This issue is fixed.

The work is now going on #1343044: Context and block translation. and #1320864: Context not respecting block language.

@nomad411 right now not, but if you use the patch from the two issue above it will works.