Strange issue, and I'm not sure if domain is at fault or features, or possibly even a core bug. If domain theme is enabled, when visiting the view, status, diff or recreate paths for a specific feature drupal will display the content theme instead of the admin theme. To reproduce:

  • Enable features
  • Set a global admin theme
  • Enable domain theme. It doesn't matter if you configure individual themes or other settings for the domains or not.
  • Visit any screen for a specific feature, for example: admin/structure/features/[some feature id] or admin/structure/features/[some feature id]/diff-- etc.

You'll see the site's content theme instead of the admin theme. Disabling domain_theme fixes the issue.

I've drilled the issue down to calling menu_get_item() in domain_theme_custom_theme(). Comment out that line and the problem goes away. I haven't looked thoroughly, but haven't seen any other pages that also exhibit those symptoms.

CommentFileSizeAuthor
#16 domain-theme-remove-obsolete-menu-check-1419090.patch824 bytesalexverb
#13 1419090-domain-theme-admin.patch676 bytesagentrickard
#11 domain_theme-path_is_admin-1419090-11.patch491 bytestanc
#5 domain_theme.module.patch760 bytesRonanLK

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (duplicate)

Odd. I assumed this was a Features bug.

#1309128: View / Recreate feature ignores admin theme when menu_get_item() is used in hook_custom_theme().

I can find no reason, however, why this only happens on that particular page callback.

fearlsgroove’s picture

fearlsgroove commented

@agentrickard: just in case you're not following the other issue you marked this as a dupe of, please check out the comment I left there. domain_theme is arguably partially responsible for this issue since it calls menu_get_item in hook_custom_theme, which happens before bootstrap. Since menu_get_item loads entities, which in turn invokes hooks that may assume Drupal is already bootstrapped, it's arguably unsafe to be called there.

Is it possible to do away with the menu_get_item call, or work around it? Commenting out that check does not seem to break context themes, admin theme or any other theme alter as far as I can tell.

fearlsgroove’s picture

fearlsgroove commented
Status: Closed (duplicate) » Active

Change status since maybe we can fix this issue in domain?

agentrickard’s picture

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

The status is correct. I goofed on the status change.

We need to research how $custom_theme is handled these days, since it seems to have changed since pre-alpha D7 when this code was written.

RonanLK’s picture

RonanLK commented
StatusFileSize
new domain_theme.module.patch760 bytes

I had this problem, so I made a quick patch for domain, to avoid unnecessary calls to menu_get_item() in domain_theme_custom_theme() on admin pages.
It's far from a perfect solution, but it does the trick.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Needs work

arg() is a recipe for fail.

agentrickard’s picture

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

Possibly a better patch in duplicate issue #1483542: Administrative theme

batigol’s picture

batigol commented

This patch isn't working for me. Drupal admin theme is still changing to my custom theme (after clearing cache for example) even when I have set different Administration theme.

BTW after clearing cache and clicking on one of my subdomain links, the subdomain appear on my domain theme. However this is happening only once (after clear cache - reload page fix this) it's probably related with drupal caching.

alexverb’s picture

alexverb commented

It shouldn't be using menu_get_item() at all as stated in hook_custom_theme(). I think when the cache is cleared menu_get_item() somehow generates the default theme for the theme callback. And since the theme callback from hook_menu() always get's priority over hook_custom_theme() you end up with the default theme anyway.

I think we should ask ourselfs why we're checking for the theme callback and not path_is_admin() instead. I guess all other modules that use hook_custom_theme() should be weighted to get priority if needed.

agentrickard’s picture

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

Makes sense. I think I wrote this piece before the D7 standards finalized.

tanc’s picture

tanc
he/him
Primary language English
Location Italy
commented
StatusFileSize
new domain_theme-path_is_admin-1419090-11.patch491 bytes

How about this quick patch? It checks that the current_path is path_is_admin and returns before menu_get_item.

batigol’s picture

batigol commented

@tanc nope, this patch could not fix this issue for me. Same as #8.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Needs work » Needs review
StatusFileSize
new 1419090-domain-theme-admin.patch676 bytes

A quick review of the docs for hook_custom_theme and it looks like we let core handle it. The attached patch works for me under these conditions:

* Loads proper theme per domain.
* Loads proper admin theme.
* Loads proper per-domain admin theme.

Admin themes also work for content creation.

fearlsgroove’s picture

fearlsgroove commented
Status: Needs review » Reviewed & tested by the community

I had the same experience when I looked at this issue: after removing the code in your patch, I had no negative effects from themes set via context, administrative theme, domain theme, or even a custom module that using menu alter to set a custom theme for specific paths. I've been using essentially this code in production for a couple months now on a number of production sites with issues.

batigol’s picture

batigol commented
Status: Reviewed & tested by the community » Needs review

@agentrickard I have tested this patch, well after applied I simply clear cache and my domain theme appear on the screen... I still have issue with DA and my domains/subdomains themes.

I have set and configured proper theme for each domain, I set proper admin theme (seven) in every of my domains/subdoamins and still nothing.

After an hour of testing:

I have installed Commerce among with few other contrib modules (Address Field, Entity API, Rules, Entity Translation etc.) lately. So I did a little digging and it seems that PayPal WPS (PayPal Website Payments Standard) (!?) module is causing this issue for me and it's not even related with domain theme (in my particular case)

Implements PayPal Website Payments Standard in Drupal Commerce checkout.
Requires: Commerce (enabled), System (enabled), Entity API (enabled), Rules (enabled), Entity tokens (enabled), Commerce UI (enabled), Payment (enabled), Order (enabled), Customer (enabled), Address Field (enabled), Chaos tools (enabled), Line Item (enabled), Price (enabled), PayPal (enabled)

...

I just feel like a wizard cause magic is happen here, or something is seriously FU with my site...

alexverb’s picture

alexverb commented
StatusFileSize
new domain-theme-remove-obsolete-menu-check-1419090.patch824 bytes

Whopsiedaysie, I should be renaming myself to mr.dupe. Sorry, ignore this patch.

agentrickard’s picture

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

@alexverb

That is a duplicate of the patch in #13. Please don't confuse reviewers by posting duplicate patches. REVIEW the existing patch.

agentrickard’s picture

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

So the patch works for you, yes?

alexverb’s picture

alexverb commented

I've had no issue's since the patch in #13 has been applied.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Needs review » Reviewed & tested by the community

OK. I'm going to commit and let people file new issues if they come up.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Reviewed & tested by the community » Patch (to be ported)

Committed to 7.x.3.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Patch (to be ported) » Fixed

Applies cleanly to 7.x.2.

Status: Fixed » Closed (fixed)

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

alan d.’s picture

alan d. commented

Thanks. I just spent the last couple of hours debugging this to find that it already fixed :)

Right, two modules in play and the other one does requires the line $item = menu_get_item();

jeffschuler’s picture

jeffschuler
Location Boulder, Colorado
commented
Issue summary: View changes

Cross-referencing #2347825: CustomError causing admin pages to appear in default theme, where the same issue occurs with the CustomError module due to a call to menu_get_item() from hook_custom_theme().