Download & Extend
Internationalization » Issues

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

Posted by sullix on May 8, 2009 at 3:41pm
Project:Internationalization
Version:7.x-1.x-dev
Component:Compatibility
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

i18nblocks module uses its own method to theme blocks... so we cannot override the Drupal theme_blocks function in themes (template.php) or in other modules (in particular : Context).

Read : #402150: Conflict with i18n block translation: Context defined blocks don't show up

Thanks

Login or register to post comments

Comments

#1

Posted by Jose Reyero on June 13, 2009 at 2:07pm
Status:active» closed (duplicate)

I'll be following on the Context module issue.

#2

Posted by makara on November 2, 2009 at 7:43am
Status:closed (duplicate)» active

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

#3

Posted by paranojik on November 13, 2009 at 12:33pm

Subscribing.

#4

Posted by Ryan Palmer on November 13, 2009 at 9:01pm

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

#632322: Context language condition support

#5

Posted by kdebaas on December 5, 2009 at 4:55pm
Title:Conflict between Context and i18n blocks» i18n blocks creates conflicts with themes and modules that override the theme_blocks function

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

#6

Posted by makara on December 8, 2009 at 8:48am
Status:active» needs review

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.

AttachmentSizeStatusTest resultOperations
i18nblock.patch3.83 KBIgnored: Check issue status.NoneNone

#7

Posted by makara on December 8, 2009 at 8:51am
Version:6.x-1.0» 6.x-1.x-dev

#8

Posted by Kameleonten on December 8, 2009 at 12:53pm

Thanks, your patch works great!

#9

Posted by kdebaas on December 15, 2009 at 5:14pm
Status:needs review» reviewed & tested by the community

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

#10

Posted by tcibah on December 16, 2009 at 12:29pm

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.

#11

Posted by kdebaas on December 16, 2009 at 1:18pm

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.

#12

Posted by Garrett Albright on December 17, 2009 at 9:32pm

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!

#13

Posted by nonom on December 29, 2009 at 2:15am

Success for me. Great!

#14

Posted by marvil07 on January 9, 2010 at 8:43am

subscribing

#15

Posted by svendecabooter on January 12, 2010 at 3:14pm

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.

#16

Posted by Hipfox on January 18, 2010 at 5:29pm

#6 patched.

#17

Posted by perandre on January 22, 2010 at 1:12pm

Will test soon, great work.

#18

Posted by sullix on January 23, 2010 at 4:13pm

Thanks !

#19

Posted by genox on January 28, 2010 at 6:49pm

Works here, too. I suggest adding this to CVS. Thank you!

#20

Posted by James Andres on February 3, 2010 at 5:24pm

Works for me, +1 to commit this.

#21

Posted by JohnAlbin on February 15, 2010 at 12:43am

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.

#22

Posted by mnzaki on February 17, 2010 at 4:24pm

Works perfectly for me.
+1

#23

Posted by hefox on February 17, 2010 at 8:15pm
Status:reviewed & tested by the community» needs work

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.

#24

Posted by hefox on February 17, 2010 at 8:38pm
Status:needs work» reviewed & tested by the community

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

#25

Posted by Jeff Burnz on March 2, 2010 at 4:02pm

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

#26

Posted by genox on March 4, 2010 at 10:16am
Status:reviewed & tested by the community» needs work

Patch fails against current dev version (march 04):

patching file i18nblocks.module
Hunk #1 FAILED at 287.
1 out of 1 hunk FAILED -- saving rejects to file i18nblocks.module.rej

#27

Posted by Jose Reyero on March 4, 2010 at 12:09pm
Category:bug report» feature request

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

#28

Posted by JohnAlbin on March 4, 2010 at 2:25pm
Status:needs work» reviewed & tested by the community

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

AttachmentSizeStatusTest resultOperations
i18nblocks-457512-28.patch3.85 KBIgnored: Check issue status.NoneNone

#29

Posted by kdebaas on March 4, 2010 at 6:44pm

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

#30

Posted by Jose Reyero on March 4, 2010 at 8:13pm
Status:reviewed & tested by the community» fixed

Great!

Committed. Thanks.

#31

Posted by genox on March 8, 2010 at 8:56pm

cool, thanks everyone!

#32

Posted by System Message on March 22, 2010 at 9:00pm
Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#33

Posted by gagarine on April 22, 2011 at 12:39pm
Version:6.x-1.x-dev» 7.x-1.x-dev
Category:feature request» bug report
Status:closed (fixed)» active

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

#34

Posted by Jose Reyero on April 30, 2011 at 10:30am
Status:active» closed (won't fix)

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.

#35

Posted by nomad411 on January 15, 2012 at 10:04pm

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

#36

Posted by gagarine on January 16, 2012 at 12:03am
Status:closed (won't fix)» fixed

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.

#37

Posted by System Message on January 30, 2012 at 12:11am
Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.