$custom_theme not being recognized

Skin plugins are inherited from parents, meaning both dave and andy will receive all of the skins made available by Fusion, and andy will receive all of the skins from dave. For example, all of those themes can set a grid width, because Fusion provides skin plugins to set them. The application of skins, however, is not subject to inheritance. So if you assign a block 3 units in dave's theme, it will have no effect on skin's theme.

The mic Andy needs to express himself might be Context or Panels. Have you experimented with either of those modules?

@mshepherd:

I think you got a bit too verbose in your bug description and caused us a bit of confusion on what the actual issue is. Just to clarify:

1. You are able to set Skins for each generation of theme.
2. Skins are properly applied to the default theme, regardless of whether it is a sub-theme or sub-sub-theme.
3. Skins are not properly applied to themes if they are active because of a 3rd-party module (i.e. Themekey or custom module using hook_custom_theme to switch the active theme from the default).
4. Do you happen to be using Dave or Andy as your admin theme?

Also, it would be helpful if you could check the weight of fusion_apply versus the module that is switching your theme. You can use phpMyAdmin to take a look at this in the System table. Here is a screenshot:

https://skitch.com/sheenad/gfn6m/fusion-apply-weight

If fusion_apply is a lower weight, or if they are the same weight and the other module's name comes after fusion_apply alphabetically, then the issue might be that the theme is not being switched until after fusion_apply has already decided which Skins apply to the current theme.

Could you also test to see if choosing a non-default theme in your User settings works correctly or not?

@aquariumtap - it sounds to me like Fusion Apply is returning the Skin settings for the default theme even when a 3rd-party's functionality is serving up a different theme from the default. Technically, $theme_key should always return the active theme, but fusion_apply_current_theme() attempts to avoid returning the Admin theme, so there is a chance that function is not working properly for a situation where a 3rd-party module is setting the theme. Another theory is that Fusion Apply is simply weighted lower than the module changing the theme and thus the Skins are being generated before the theme has been switched.

@mshepherd - Thanks for all your thorough testing!

Now, my best guess is that fusion_apply_current_theme() is returning an incorrect result when a 3rd-party is changing the active theme.

Lines 676-679 of fusion_apply.module are my best guess as to the cause of this issue:

  elseif (!empty($custom_theme) && drupal_theme_access($custom_theme) && !($exclude_admin_theme && $custom_theme == variable_get('admin_theme', '0'))) {
    // Don't return the admin theme if we're editing Fusion Apply settings.
    $current_theme = $custom_theme;
  }

Updating title to be about $custom_theme, not inheritance. Side note: currently there are unit tests for inheritance, but not for $custom_theme. Need to add.

The global variable $custom_theme is no longer in use. It has been replaced by menu_get_custom_theme(). I've filed an issue with the core docs team. I'll work on an Accelerator patch.

Here's a patch. I should write a test as well.

Tested and works great. Thanks!

EDIT: I should elaborate:

I installed the ThemeKey module and set up a rule to serve Fusion Starter for one node page and use a custom Fusion sub-theme as the default theme. I assigned different skins to one block on that page to each Fusion Starter and my custom Fusion sub-theme.

I confirmed that the issue exists - the skin assigned for my custom sub-theme persisted even when Fusion Started was served by the ThemeKey module.

Then, I applied the patch and cleared site cache. Now, the appropriate skin is being displayed for the page using the Fusion Starter theme.

I did not encounter any warning message or odd behavior.

Committed.