I had Domain theme running nicely, and then I installed a whole glut of modules to implement the features of Advanced Profile: panels, nodeprofile, nodefamily, various helper modules - quite a big set. Domain theme now has no effect - it is as if it isn't installed. No quirky behaviour as such, just no change at all: Domain 0 theme is applied to the subdomain no matter what. I can't see any modules that would be setting the theme, even so I've tried weighting domain theme variously from -100 to 100 and no effect. I've tried reinstalling (domain theme module), different themes etc and still the same.

Any suggestions as to how I can debug this to find the cause/clash?

I'm running it on a dev site so if you fancy a poke around I can let you in.

Thanks, Stephen

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Do a grep or other search of your modules and themes directories for the phrase:

global $custom_theme

To see where else this value is being set. $custom_theme is the override value of the default site theme.

scedwar’s picture

scedwar commented

I ran a grep -R on my modules directory on 'global $custom_theme' and '$custom_theme'. The only modules I got were og and themesettings api. Only og is enabled.

I can easily do a fresh db dump from my live site to give a clean base for a new install, but I'm keen to get to the bottom of this in case it is something that needs fixing. Any thoughts?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

OK, just try $custom_theme. In the case of Domain Theme, the line is:

    global $_domain, $custom_theme;

So the original pattern I gave you won't work.

scedwar’s picture

scedwar commented

Sorry, I meant to be clearer: I ran both greps on my modules directory as I spotted that domain theme didn't come up! (although the readme did):


grep -R 'global $custom_theme'
grep -R '$custom_theme'

The net result of these was that nothing surprising was picked up, only domain theme (of course) and og (enabled) and themesettings api (currently disabled).

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

And you have set different themes for the different sub-sites, right?

You can always debug by putting some print statements in your code.

Inside domain_theme_menu() you might put a print $custom_theme above and below the parts where it gets set. Then you might do one inside your page.tpl.php:

global $custom_theme;
print $custom_theme;
scedwar’s picture

scedwar commented
Status: Active » Postponed

Thanks for the tips. I'll be rolling a fresh dump of my db anyway so I'll see if this goes away or not in case I've broken something else.

scedwar’s picture

scedwar commented
Title: Domain theme clash with Advanced Profile? » Domain theme not applying to subdomains?
Status: Postponed » Active

Ok. I did a quick dump of the live db onto the dev site last night and I've been tinkering today. I've set the domain theme weight to 100. The behaviour is consistent: Domain theme only applies the theme to the subdomain if the page does not use the filtered HTML input format!

For example, the contact form, views, any php input type, login page, register page, has the correct theme.
Any node display of filtered HTML does not display the correct subdomain theme, but shows the domain 0 theme.

The following filters are installed and enabled for filtered HTML:

Code filter
HTML filter
Inline file filter
Inline images
Lightbox filter
Line break converter
Quote filter
Smileys filter
URL filter
reCAPTCHA Mailhide

Any ideas?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

One of those modules/filters is overwriting $custom_theme or (even worse) calling init_theme(). Though I cannot imagine why.

Try grepping for init_theme

Filtered HTML works as expected on all the sites I can test on.

scedwar’s picture

scedwar commented

Hmmmm. The good the bad and the ugly! Grepping (is that a verb?) on init_theme

MY DISABLED MODULES:
modules/sections/sections.module: // Never *ever* use t() with %name in hook_menu OR init_theme() get's fired for theme_placeholder
modules/themesettingsapi/themesettingsapi.admin.inc: init_theme();

MY ENABLED MODULES:
modules/print/print.module: init_theme();
modules/print/print.module: init_theme();
modules/print/print.module: init_theme();
modules/print/CHANGELOG.txt: Added init_theme to fix bug with logo.
modules/adv_profile/jstools/jstools.module: init_theme();
modules/adv_profile/jstools/activeedit/modules/system.inc: init_theme();

I'll put some of these criminals in the dock and look for confessions...

scedwar’s picture

scedwar commented

Still no luck.

1) I deleted (not just disabled) all of the modules that reference init_theme custom_theme etc with the exception of domain_theme. Still getting the same behaviour.

2) I've put a print $custom_theme in my page.tpl in the title and the footer. On the pages where my sub domain theme should be applied, sure enough that is the value of $custom_theme at the top and the bottom of the page, but the theme isn't being applied.

3) I've disabled every single input filter for the filtered HTML type. Still the same behaviour.

4) If I take one of my filtered HTML input type pages and edit the input filter to PHP, click save - the correct theme applies to the page as expected.

5) Finally, I've tried switching between a few other themes and the behaviour is also consistent, for example with Garland/Minnelli, so this doesn't appear to be a custom theme issue.

At least I'm getting consistent behaviour! ;-)

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

The themes are active under Admin > Build > Theme, right? Domain Theme should not allow you to select inactive themes.

You are logged in, and not viewing cached pages?

Anything special about the filters? New tags? Additional filter modules?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Still cannot replicate. There is a known conflict for administrative pages if you set an Admin Theme, but that does not seem to be your issue.

scedwar’s picture

scedwar commented

The themes are active.

All behaviour can be observed and is consistent as an anonymous user, authenticated user or logged in as admin.

I'm using multiple web browsers to test and forcing the cache to clear with ctrl refresh. Changing the input type for a page changes the theme so the cache certainly isn't stuck (either on the local computer or on any proxy/caches on the network).

-- Pages on domain 1 that display the wrong (domain 0) theme ---

(with a "print $custom_theme" in the page title and footer outputing the correct name for the domain 1 theme)

1)filtered HTML input format
- no input filters enabled
(same behaviour with various filters enabled as per previous post above)

2) FULL HTML input format:
Filters enabled:
-Code filter
-URL filter
-Line break converter

-- Pages on domain 1 that display the correct (domain 1) theme ---

3) PHP input format page:
- PHP filter active and no others

4) 'system' pages, for example the contact form, faq list, home page node list etc and admin pages (for admin users only of course)

scedwar’s picture

scedwar commented

Further testing...

The PHP input format seems to be controlling something. If I enable the PHP input filter for any of the input types (e.g. filtered HTML!!!!) sure enough the theme is applied correctly. If I disable the PHP input filter for any of the 3 types, the wrong theme is displayed.

scedwar’s picture

scedwar commented
Status: Active » Fixed

I've done a fresh copy of our live site, code and db. Installed 1.1beta1 and the problem seems to have gone. I've replicated all of the domain settings and yet everything seems fine. Intentional or otherwise, problem seems to be fixed. Thanks Ken!

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

scedwar’s picture

scedwar commented

I've now finally had an opportunity to return to this issue. In short, the advanced_profile module definitely overides the theme. However, "Setting Domain Theme execution order: -100" has the effect of ensuring the correct theme appears.

Will post if anything else crops up.

EKM’s picture

EKM commented

I had this problem also in Drupal 6 where the admin didn't always work properly on dev, but was fine on production.

The cause is apparently various contrib modules not checking indexes and such before using them, triggering various warnings, which causes watchdog & syslog calls to fire of init_theme(), which sets global $theme with a null value, which skips over in the next init_theme() call, because it's set, even if it's null.

function init_theme() {
  global $theme, $user, $custom_theme, $theme_key;
  // If $theme is already set, assume the others are set, too, and do nothing
  if (isset($theme)) {
    return;
  }

Possibly, the isset(), should be a !empty() - (I'm not familiar enough to with the theme subsystem to say one or the other).

You can either change error_reporting in your php.ini, or turn off syslog.
error_reporting = E_ALL & ~E_NOTICE

Also, contrib modules should check their indexes before using them!