Posted by xamanu on March 14, 2009 at 9:59pm
20 followers
Jump to:
| Project: | Context |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
With i18n's "block translation" module and context_ui enabled none of the context defined blocks show up.
Both context_ui and i18n's "block translation" use the hook_theme_registry_alter()-function to override the $theme_registry['block']['function'] value to let drupal run through their proper theme-function. Whoever is getting called first is going to be overridden :-(
Comments
#1
Hey Felix,
Yea, this is rather problematic. I haven't had time to look into this at all, but I totally get the issue. Do you see any clear options?
#2
Hello,
I have the same problem. At my site the function from i18n is called last. So I have altered the function i18nblocks_theme_blocks($region) in i18nblocks.module. Instead of calling the core function block_list() I have called the function context_ui_block_list() from the context_ui module when the context_ui module is present. My final code looks like this:
function i18nblocks_theme_blocks($region) {
$output = '';
$i18nmenu = module_exists('i18nmenu');
$i18nblocks = _i18nblocks_list();
/* FIX by RHOS : BEGIN */
if (module_exists('context_ui') ) {
$list = context_ui_block_list($region);
} else {
$list = block_list($region);
}
if ($list) {
/* FIX by RHOS: END */
foreach ($list as $key => $block) {
// Configurable blocks, may be localizable.
if ($block->module == 'block') {
if (isset($i18nblocks['block'][$block->delta])) {
$block = i18nblocks_translate_block($block, $i18nblocks['block'][$block->delta]);
}
}
elseif ($i18nmenu) {
// Replace menu blocks by their translated version.
if ($block->module == 'menu') {
$block->content = i18nmenu_translated_tree($block->delta);
}
elseif ($block->module == 'user' && $block->delta == 1) {
$block->content = i18nmenu_translated_tree('navigation');
}
}
// Finally, render the block using standard theming.
$output .= theme('block', $block);
}
}
// Add any content assigned to this region through drupal_set_content() calls.
$output .= drupal_get_content($region);
return $output;
}
Hope this information will help for providing a generic solution for this problem.
Robin Hos
#3
I have the same problem too.
Your fix works! But, it is not a good solution...
I wrote an issue for i18n : #457512: i18n blocks creates conflicts with themes and modules that override the theme_blocks function
#4
Subscribing here, though not plans to fix it atm on i18n side.
My suggested fix: Add the incompatibility to the documentation.
#5
Jose, yea I agree - at this point we should just document the problem.
#6
Subscribing here, since most of our sites need i18n, we suffer a lot from this problem. Any plans or more info about this problem would be much appreciated. We're using the 2.x branch but the problem seems to exists there too.
#7
Luckily I was able to disable the i18n_blocks module on my site, but I would still like to follow the development of this issue.
#8
I have come across the same issue, but I really need both modules. I'm experimenting with a simple fix by setting the weight of the context modules to 300, making sure they are run after the i18_blocks module. A quick look around doesn't seem to reveal any issues. But I'll keep you posted when they start popping up.
#9
Subscribing.
#11
I can confirm that the weight fix is now running without any issues on two projects.
#12
These modules: context, i18n blocks are just not compatible. See http://drupal.org/node/313262
#13
@stijndm
I'm bit confused, where do you set module weights?
#14
@marcushenningsen, I believe that the only way is to modify values in the database directly. Modify the values in the 'weight' column in the 'system' table.
#15
I can't believe that it won't be fixed. Context is a great module, but there are websites that just can't live without the i18n...
#16
Modifying weight values doesn't help, because if context module is called after i18n block, block translations doesn't work. I've tested only custom block title translations with http://drupal.org/node/541048 patch applied.
So the only way to use both modules is #2 i18n hack, but it works only with 6.x-1.0.
#17
Subscribing.
#18
Dboulet, thanks for the info.
MantasK, it seems to me that changing the module weight does work with block translations, but we may be testing different types of blocks. I made a block with Views2 and localized and translated the block title through the i18nviews module. This block is ouputted through the Context module and everyhing seems to work.
I'll keep testing this, though, and report back.
stijndm, are you still not experiencing issues with the weight fix?
#19
This is a show stopper for a lot of people including myself. Context has so much promise, but only if it can be used alongside other common modules. Translations are a core part of many Drupal websites. This issue needs to be properly resolved. Please consider taking the 'wont fix' off this issue.
#20
@mrfelton As I posted in #2, what we need here are options. I certainly understand that i18n is critical for many sites, and you can certainly use **most** of the i18n package with context - but the blocks stuff, not so much. Both i18n and context use the same hack to take control of block visibility and we don't have a solid idea of how to approach a fix. It's simply not clear what a fix looks like right now.
#21
@jmiccolis: fair enough. I just wanted to add a little more weight to my post that a simple 'subscribe'! I don't have any time to try and fix this myself, but will certainly join in any further discussion on this.
#22
There's a patch added today by "makra" that solve this conflict at: http://drupal.org/node/457512
#23
I reopen because apparently it was fixed on D6 but on D7 it doesn't work.
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.
#24
Confirmed in current 7.x-3.x-dev. Not sure what to do here to fix this.
#25
has anyone solved this problem?
thanks
#26
Think I'm going to approach it from this angle for now: Node Blocks
(seems that is more appropriate than (Nodesinblock or perhaps something like this Block reference if you want to share content.)
#27
This issue was closed as won't fix.
That means it was never fixed, and a maintainer decided not to fix it.
I'm personally not going to close it again, as it feels like d7 has a huge possibility of fixing this issue for those that have time.
#28
Just to add some clarifications.
The D6 issue was fixed here just because someone else posted a good patch #457512: i18n blocks creates conflicts with themes and modules that override the theme_blocks function
I don't think the issue still exists for D7. The i18n part at least has been fully reworked and it shouldn't conflict with context now (at least for block visibility).
The D7 issue seems to be 'blocks added by context' are not translated, which is different to 'not showing up'. So please open a new issue for D7. (But before try changing module weights and see what happens).
#29
For the context + i18n block issue for D7, check out:
http://drupal.org/node/1320864
There is a patch available.
Kristen