hook_custom_theme() does not work as expected

So what's the intent here? If drupal_theme_initialize is called, why does it call menu_get_custom_theme with $initialize FALSE? So the patch seems correct I set it to CNR so that the bot can judge it -- but if it goes through (should) then the call in full bootstrap needs to be removed.

+

We have tests in core that verify that hook_custom_theme() works. As far as I know, those tests pass. Do you have an example of an implementation of this hook that proves it doesn't work?

Also, http://api.drupal.org/api/function/_drupal_bootstrap_full/7 calls menu_set_custom_theme() before it calls drupal_theme_initialize(), so there is no problem there. Is there somewhere else in the bootstrap where drupal_theme_initialize() is called earlier?

I felt this was not critical, sorry for not checking for those tests.

Hm, that is a bit unfortunate that merely calling l() results in the theme system being initialized, but yeah, there isn't much we can do about that :( At least the list of hooks that can run before hook_custom_theme() is pretty limited.

Was in one of t'ified strings in the l() functions a % theme placeholder? This would explain the theme init as I know.

No, it's actually l() itself: http://api.drupal.org/api/function/l/7

In Drupal 7, % placeholders no longer trigger the theme system.

Actually %wildcard may trigger the theme system, and this does cause issues. This would be mainly be limited to the entity system loads triggering themed output.

It is a complete chicken and egg thing going on here, with the menu potentially defining the theme but the theme may need to be invoked before defining the active menu item.

This strongly suggests that entity_load() should never invoke the theme layer, and this makes more sense as the entity load is cached independently of the theme anyway.

So some of the limitations / wtf with hook_custom_theme(), all by design.

1. Internal calls to menu_get_item() within hook_custom_theme() [or any related menu item lookups] results in a failure.
2. if theme() is invoked before menu_set_custom_theme()
3. there is a race condition where the module with the highest system weight wins

It sounds like you're talking about the use of % in menu wildcards. Above we were talking about t() % placeholders, which don't trigger the theme system.

If you're choosing the theme based on the menu item, it's probably best not to use hook_custom_theme() at all, but rather to use the 'theme callback' property in hook_menu().... However, I'm guessing this problem would occur with that too.

I think you're right that a module which intentionally triggers the theme system during entity_load() is probably doing something wrong, but with l() doing it by default I guess there are ways it can happen by accident too...

For Drupal 8 and beyond, I would think something like #981654: Use several themes during the same page request is the way to handle these kinds of issues once and for all.

This has to be fixable, as it poses several nasty problems for context modules (og, context, domain access).

Looking into this for a site now. Perhaps it's not fixable, but if so I need a suitable workaround. If I find a patch that works, I'll post here.

There is an l() in system_token_info() -- $date['custom'] -- that can get called very early in the load process and may cause part of this issue, however, removing that still throws a problem when certain filters run and implement tokens.

In my case, the culprit may be media_filter and media_token_to_markup().

But even if I eliminate that, the l() in system_token_info() still causes the problem. Both need to be fixed.

This solution "fixes" the problem in a custom module. Nothing else I did could solve the race condition.

/**
 * Implements hook_init().
 */
function custom_init() {
  // This is a very nasty hack around https://drupal.org/node/1120188 and
  // https://drupal.org/node/943616.
  // FORCE the theme to re-initialize.
  unset($GLOBALS['theme']);
  drupal_theme_initialize();
}

What has been happening is that on cache clear, the theme gets initialized twice, but one of the passes doesn't invoke hook_custom_theme(). I think that's related to the l() function in system_token_info(), but there were also calls coming from contrib that made the problem unpredictable.

I'm going to mark this "won't fix", which is more accurate than "works as designed."

I am coming to this issue from #2147409: Interaction with Context OG. I think agentrickard is right about l() causing part of the problem with some hook_custom_theme() implementations.

From what I can tell the problem is that any implementation that calls a function that might end up calling drupal_theme_initialize() will cause the default theme to be displayed instead of the custom theme. Since drupal_theme_initialize() calls menu_get_custom_theme() without the $initialize parameter (and for good reason because otherwise we would end up in an infinite loop), the theme that gets initialized will always be NULL because our hook_custom_theme() has not returned yet.

Attached is a backtrace for one case where this was an issue for me. My hook_custom_theme() implementation is very much like the one in og_theme_custom_theme(), calling og_context() which after a cache-clear (like when saving a View, Node, etc), the theme is not properly set on the next page load.

I'm also attaching a patch that so far resolves this for me, but I think there might be other places where drupal_theme_initialize() might be called at an inappropriate time.

We can also change theme of existing path of core module using below code :

function custom_menu_alter(&$items) {
$items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['theme callback'] = 'norden_core_default_term_theme';
$items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['theme arguments'] = array(3);
}
function custom_default_term_theme($v_name) {
return variable_get('theme_default', '0');
}

It seems this is a duplicate of #2086335: Bootstrap issue with theme initialization causes hook_custom_theme() never to be invoked.

That is just one of many possible trigger for these symptoms. Short solution, never call a theming function before the menu system has initialised :(

To add to what pragna said above in comment #17:
Let's say you want your theme to kick in for users who are editing a certain type of node, but want the normal (admin) theme to display otherwise.

function MYMODULE_menu_alter(&$items) {
   $items['node/%node/edit']['theme callback'] = 'MYMODULE_set_custom_theme';
   $items['node/%node/edit']['theme arguments'] = array(1);
}


function MYMODULE_set_custom_theme($node) {
  
   if($node->type == "THE_CONTENT_TYPE"){
      return "MY_THEME_NAME_HERE";
   }
   //otherwise just use the normal theme
   return $GLOBALS['theme'];
  
}

For anyone who is considering using agentrickard's workaround in #15, you may also need to call drupal_static_reset('theme_get_registry'); so the theme registry can be rebuilt. Without that, I was running into an issue on certain pages where some of the content would get rendered with the default theme while other content would use the custom theme.

So the workaround I implemented looked something like this:

/**
 * Implements hook_init().
 */
function custom_init() {
  // This is a very nasty hack around https://drupal.org/node/1120188 and
  // https://drupal.org/node/943616.
  // FORCE the theme to re-initialize.
  unset($GLOBALS['theme']);
  drupal_theme_initialize();
  drupal_static_reset('theme_get_registry');
}

I was running into this again recently but the previous patch alone wasn't working, nor did the one in #2086335: Bootstrap issue with theme initialization causes hook_custom_theme() never to be invoked. I found I also needed the patch in #1814516: Subpathauto causing admin pages to appear in default theme and had to update my implementation of hook_custom_theme() to not use menu_get_object(); otherwise the callstack looked something like node_load() => text_field_load() => check_markup() => media_wysiwyg_filter() => media_wysiwyg_token_to_markup() => drupal_theme_initialize()

This issue about DA and AMP is related: #2909926: Domain access and amp doesn't work!

I had a similar issue as #22. Instead of using node_load, I queried the database directly to check my condition:

function mymodule_custom_theme(){
  $nid = arg(1);
  $query = db_query("
        SELECT node.type AS type
        FROM {node} node
        WHERE (node.nid = :nid)",
    array(':nid' => $nid));
  $results = $query->fetchAll();
  $node_type = $results[0]->type;
  if($node_type === 'target_node_type'){
    return 'target_theme';
  }
}