Download & Extend

Use hook_domain_bootstrap_full() to set $conf['default_theme'] rather than hook_custom_theme()

Project:Domain Access
Version:7.x-3.4
Component:- Domain Theme
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

the request
To be able to set theme_default via hook_domain_config().

Basically, to provide a fallback to hook_custom_theme() when the theme() layer is initiated prior to calls to menu_get_custom_theme().

i.e. any theme function called during entity load.

The issue (verbose background info / debugging steps)

On most nodes on this site, you edit and switch to admin theme and save, revert back to the correct theme, however some nodes will show the default domains theme just after saving. Refreshing the page will show the correct domains theme.

Adding some debugging information on the menu.inc, everything appears fine. Exporting the code / db locally, everything appeared fine (a missing local file bypassed the call to theme()).

Some debugging output in menu_get_custom_theme() on save produces:

    menu_get_custom_theme(): hook_custom_theme returned seven (admin theme)
    Content type Node title has been updated.
    menu_get_custom_theme(): hook_custom_theme returned community2012 (correct domain theme)

Moving into drupal_theme_initialize() we get this:

<?php
 
print variable_get('theme_default', 'bartik'); // main domain default theme
 
print (!empty($user->theme) && drupal_theme_access($user->theme) ? $user->theme : variable_get('theme_default', 'bartik')); // master2012 (default theme on master site)
 
print $custom_theme; // undefined
?>

Since $custom_theme = menu_get_custom_theme(); doesn't initialise the theme, I'm guessed that this was being called via a theme function prior to menu_get_item() :(

In theme() function, the following code found the cause:

<?php
 
global $theme, $user;
  if (!isset(
$theme) && $user->uid == 1) {
    if (
is_array($hook)) {
     
drupal_set_message('Function theme() called, $theme was not set. The $hook parameters were: ' . implode(',', $hook));
    }
    else {
     
drupal_set_message('Function theme() called, $theme was not set. The $hook parameter was: ' . $hook);
    }
  }
?>

which spits out:

    Content type Node title has been updated.
    Function theme() called, $theme was not set. The $hook parameter was: image_resize_filter_image

Tracing this back even further:

This is called via the filter module as the Image resize filter is enabled on the selected filter on the body field of this content type, called via the Text module fields text_field_load() via _text_sanitize() / check_markup() / theme('image_resize_filter_image').

Changing to a non-cached filter solved the issue (but not an option as caching is vital on this large site).

Cross-posting: I created a new issue to resolve this on the Image resize filter: #1870888: Calling theme() within a cached filter breaks hook_custom_theme(); it would be nice to allow modules to mis-behaviour and not break the site, so leaving open for feedback.

Comments

#1

Status:active» closed (duplicate)

Please do not cross-post issues.

There is no hook_domain_config(). This sounds like a problem in Image Resize Filter.

#2

Title:Optionally set domain theme using domain config.» Use hook_domain_bootstrap_full() to set $conf['default_theme'] rather than hook_custom_theme()
Status:closed (duplicate)» active

afaik, there is no documentation anywhere that states you shouldn't use a theming function when implementing a filter or even during a field load.

OK, you have ruled out Domain config integration, so after briefly looking at DA bootstrap, maybe have Domain Theme use a custom implementation of hook_domain_bootstrap_full() to update $conf['default_theme'] to build in some robustness into the system?

Also, this would allow users to continue to use $user->theme with Domain Access.

I actually see this as a bug report, but leaving as a feature request as it is such an edge case. I will not reopen if you consider this not worthy of fixing.

#3

I originally closed this thinking that the problem is in the other module.

I can see the benefit to moving this from hook_custom_theme(), actually. That might also let use remove the special-case handling of admin themes.

Patch?

nobody click here