Context only knows about the current theme

This is a known issue ;)

...We're open to ideas for the best way to solve this, and make the context_ui interface better in general. Personally I'm not happy with how the block admin interface throws you into different themes to setup blocks. I know technically it makes this easier/possible, but from a users perspective it's confusing and has lead to all kinds of admin confusion on sites I've seen.

subscribe

what I have been doing is using http://drupal.org/project/admin_theme to make admin/build/context use the frontend theme while using an admin theme for all other admin/* pages

What would be nice, would be to provide tabs for each installed theme above the blocks area in context_ui that changed the list of regions when clicked.
this way you would be able to have different block configurations per theme, and manage them in context_ui.

We'll take a look at this after a stable release of the Drupal 6 branch is finished : )

Added related issue here: http://drupal.org/node/443114.

Subscribing...

subscribing

subscribing

subscribing

Moving to correct version.

Tracking. An important aspect of this bug is that if you edit a context in the wrong theme (one with different regions), it deletes any block configurations you have for regions that aren't in that theme. Whoops!

Marking active since per #4 this issue was waiting on a stable 6.x branch.

Some quick possible solution from the UI perspective:

split by theme:

• prepend theme regions with the theme that is generating them
• add a theme tab in the regions selection list that let's you switch between regions for different themes

make one big list and filter down:

• adding all regions from all active themes and adding a context condition that removes the one's from the not-selected theme

My 2 cents:
I would say the most logical choice from UX point of view would be an additional dropdown box on /admin/build/context with all enabled themes but preselected with the default theme. This would mean you can't have cross-theme contexts, but that sounds like a very confusing bad thing to me anyway. (If you have different themes, it would make sense they are per definition in another context)

In 90% of the cases people won't be building contexts other than for their primary theme so you should not confuse them with big lists/all regions or prefixes. Keep it simple and usable.

subscribe

add a Theme context option...

selection box for simple setup - show all themes that are enabled, you select the ones for the context
or textbox for advanced setup - you type in themes... being able to choose in which themes the context applies AND in which it doesn't applies (~) AND in optionally all themes starting with a pattern (*)

i am not sure if this is the right place, but I would like to be able to select my theme reaction based on information I might get from browsecap module. that way if I know that someone is on a mobile device, I can deliver that theme.

First let me say this is a very cool module. Thank you so much for developing it. Here's my vote regarding this issue. If idea #15 is doable, its seems a logical approach. I assume it would address the admin theme issue and if someone is using a module like page_theme. I am more interested in accommodating site sections using different themes. Site sections seem to be more prone to multiple block configurations than the admin area.

thanks

On second thought it's better not to prepend the theme regions with the theme they come from, as that would kill the cross theme use case.

You could use the theme region select box as proposed by #13 to filter regions by a theme, so you could parse all regions from the info files of all the active themes and than keep the list sane with the JS selection box (that could have the default theme selected as default).

For dealing with the cross theme context use case we could create a superstructure of context sets on the overview page. The UI could be similar to the CCK fields group concept. Than you could per context set define in what theme(s) it should be active. That would make it trivial to migrate/share contexts between themes (if they share the same block regions).

in reply to#17

This is definitely not the same issue and I don't think that browscap support is part of the scope of the context module. So you'll probably need to get this developed yourself.

That said, you'll need
-a condition that is based on browscap
-a reaction that let's you set the theme

Check out http://drupal.org/project/context_extras for learning how to do that.

I just tried this module that extends context to have an active theme reaction. Works great.

http://drupal.org/project/context_reaction_theme

subscribe

Subscribe.

I think that this would be fairly easy to implement via changing the theme early in the bootstrap process, but the change to admin interface, similar to the Drupal block system, would not be the greatest UI. But this may be the only way to interact with the module via contrib. I'll dive into the code and see if I can find a cleaner solution.

@yhahn - any progress with this issue internally?

Subscribe.

I'm interested in this as well, mainly for block positioning per theme instead of just the default theme. In context_reaction_block.inc i've noticed that the $theme_key variable is just pulling the default theme, then passing it into the system_region_list function to pull available regions. For a quick(ish) fix with just one alternate theme couldn't I just dupe the existing block reaction as "block_alternate" or something and in there manually define $theme_key as whichever theme I'd want to place blocks in? Any big reason I'm missing that something like that wouldn't work?

For a quick(ish) fix with just one alternate theme couldn't I just dupe the existing block reaction as "block_alternate" or something and in there manually define $theme_key as whichever theme I'd want to place blocks in? Any big reason I'm missing that something like that wouldn't work?

Themes can have different regions which may not be available

The best approach that I could think of is:

Have the form in two parts, a theme choicer and block context config. Theme defaults to main theme, rather than the admin theme.

Via an onchange listener on the theme select, switch block context via ajax

For the blocks, there needs to be a region switcher, maybe similar to the block dnd. There would also need to be an unassigned region area for active blocks that are not assigned a valid region for the themes active context.

Then, the entire plugin needs to be refactored to use the selected theme etc,....

Seems like a fairly significant task, but I couldn't see an easier better way.

subscribe

Ok i realized that if you keep your contexts separate (ie one context at a time for main theme, one context at a time for alternate) you can switch the default theme to your alternate, place the blocks via context and save, then switch the default theme back and your alternate theme contexts still work. This works great for instance with a mobile theme that has completely different regions than your regular theme, and as long as you don't save contexts that were created in the original theme while the alternate is active, this works pretty well.

subsciribing

I think that this is a required feature for Context going forward.

Subscribe

Subscribe, and thank you for all your work.

I need a second theme for facebook canvas pages. I suggest this will become more common.

Jerry

Same issue with Domain module.

So seems this "little" issue has been here for more then 3 years? Ufff, anyway here is some D7 patch, hope it works and gets into D6 also

http://drupal.org/node/988222

subscribing

+1 Subscribe

+1

+1

There is a workaround! This requires that you are using an administration theme and possibly the 'Administration theme' module. It might work without it too.

In order to get this to work I switched the default theme to my admin theme and then configured my context (in this case for an overview or dashboard) how I would like it. Once I am done with that I can switch my default theme back to my desired front end theme, but the context will still execute correctly for my admin theme!

Note that you cannot edit that context since your now only showing the default themes regions! Context is not administration theme aware. You will have to switch themes again.

Hope this helps someone out.

I second the comment that suggested to expand context to show all enabled themes so you can place blocks into regions from other themes when used.

I have a similar case which I think is related.

There is a main theme and a mobile theme, so the themes switch and can have different block areas.
I can get context to not display its blocks on my mobile theme by using mobile context as well as the path condition used to place the blocks on the correct page.

But if I go into my blocks on the mobile theme and activate the same block, it'll display as long as I do not give it a path condition.
So basically I cannot use the blocks in a different theme if they are instructed to display on the same path.

I think this is related because even though these blocks exist in different regions, context is preventing the blocks in the other theme from being displayed because they both share the same url.

Does that sound right?
Considering now how mobile is increasing even more, theme switching is likely to be much more common to manage different devices.
Therefore handling this would appear to be important.

Else you'd have to disable the path based contexts and go back to using blocks.

Thanks

Hmm. This is a bugger isn't it. Basically impossible currently to use context on sites that use more than one theme.

+1 Solving this would make developing mobile themes so much easier. I tried el_reverend's workaround but did not work for the mobile theme

subscribing

I have tested alberto56's patch (http://drupal.org/node/988222) in D6 - Context 3.0 and it works. Here is my SVN patch file to see all regions in Context.

So I'm still getting errors about regions not being seen theme-site wide. With that patch, any suggestions? It seems like this should be a standard in context.

So I'm getting Context to recognize the regions between the two active themes, but it doesn't seem to recognize the content from the block... When I assign a block, the output puts:

<a class='context-block-region' id='context-block-region-left'> Left sidebar </a>

but then, nothing else...

Related in contrib: http://drupal.org/project/context_condition_theme

Context Layouts also fails to see the layouts of any theme except the active theme, which may be an admin theme.

Is there maybe a maintainer who could let us know a bit more about the status of this issue? It seems to me that this feature is not in the latest build.

+1 any news on this one?

Doesn't seem as though there has been much research on this ticket. I had reason to look into this further and am applying my findings for the 7.x branch (hence why I updated Version). I have narrowed down that the issue seems to be underlying at line 15 inside /context/plugins/context_reaction_block.inc file:

$theme_key = variable_get('theme_default', 'garland');

This variable ($theme_key) is used further down in the file (line 61), which passes the 'theme_default' setting to render the regions for the theme. My quick suggestion will be to add a function that makes a more intelligent decision for setting $theme_key (rather than just getting default active theme). Although this sounds simple, my reason for a fix is more complex and directly ties to comment #47, the issue primarily is due to Context UI does not reload 'reactions' based on 'condition' when administering a context.

    foreach ($this->system_region_list($theme_key, REGIONS_VISIBLE) as $region => $label) {
      $form['blocks'][$region] = array(
        '#type' => 'item',
        '#title' => $label,
        '#tree' => TRUE,
      );
      foreach ($this->get_blocks($region, $context) as $block) {
        if (!empty($block->context)) {
          $form['blocks'][$region][$block->bid] = array(
            '#value' => check_plain($block->info),
            '#weight' => $block->weight,
            '#type' => 'markup',
            '#tree' => TRUE,
            'weight' => array('#type' => 'weight', '#delta' => $weight_delta, '#default_value' => $block->weight),
          );
        }
      }
    }

It seems to me that this is a can of worms. There's the desire to show the regions for a particular theme in the blocks reaction and there is added complication using the domain_theme module.

When context_reaction_block->get_blocks() is called, it reads the theme_default key which may or may not be the active theme. Whether you use multiple themes in a single site or multiple domains with their own theme means that we can not rely on the theme_default variable holding the correct value.

This has implications on building the cache of blocks. It is entirely possible to have an empty cache and load the block data for an alternate theme into the cache which subsequently breaks the display when viewing the theme_default theme.

There are related issues to variations on this problem:
https://drupal.org/node/988222
https://drupal.org/node/1787830

There's a patch on one issue which allows switching the regions being shown to a specific theme whilst the other has a patch to show the regions of all active themes.

Neither of these patches seems to address the flaw in get_blocks. My particular use case uses the Context Condition Theme module to show blocks based on the currently active theme. (My regions are the same on all active themes so switching is not necessary) When the cache is cleared and the first hit to the site is on an alternate domain using a different theme, it builds the cache of blocks for that context but keys it against the theme indicated by theme_default.

I understand that this is possibly us overstepping what context was designed for originally but with the context_condition_theme module in existence, the issue could do with being solved.

We have had reasonably success so far by changing
$theme_key = variable_get('theme_default', 'garland');
to simply
global $theme_key;

As stevesmename mentions in #51, there is that critical line which chooses the theme_key. I know we have added complexity due to domains but I think we can solve this.

Perhaps the caching of the reactions needs to key off the conditions better so they can be built and cached.

EDIT:
I've found a related issue on the domain module which may help reset theme_default for my use case but the fact remains that with the theme potentially changing, it is not correct to assume that the blocks will be built for theme_default https://drupal.org/node/1870890

ANOTHER EDIT:
If theme_key is a variable that affects the blocks that are available on a site - especially when dealing with domains, it should be appended to the block_info key in the cache.

Instead of writing a patch due to the complexity of testing, I went a different route and wrote a module. I wasn't planning to contribute this module but thought it might give insight to my thoughts on how multi-theme block could work. It has some quirks and users are welcome to submit their issues to my project queue for further investigation.

https://drupal.org/sandbox/stevesmename/2173907
NOTE: SEE COMMENT #55 BELOW (it seems this suggested module is similar to mine)

Patch in https://drupal.org/comment/7850475#comment-7850475 solves the issue and works with context_omega module.

This module would appear to be related to this issue:
https://drupal.org/project/ctr

The mentioned module, Context Theme Reactions, https://drupal.org/project/ctr, solved the issue for me.

I'm using theme key to switch between mobile and desktop version in one of my client sites and It was impossible for me to set context for the mobile version since the issue, with CTR I was able to see all the region, even the regions of the mobile theme, and it was easy to set the contexts for the mobile version, the module looks a little buggy since the theme filter in the reaction configuration doesn't work, but is not critical.

My two cents

Re-attaching patch from https://www.drupal.org/node/2001112#comment-7850475

I confirm that in my case also where I use ThemeKey module the Context Theme Reactions did the trick. Remember to clear caches after the ctr installation because you will not see the blocks reactions if you don't.