all was working well until we made a few changes, we have no idea what caused the problem because multiple developers have changed it. We are unable to figure out the problem

we have selected :
http://www.site.com/admin/settings/admin/theme

Rubix as the theme. Also enabled the rubix theme from http://www.site.com/admin/build/themes .

But we can only see the default theme selected from the theme settings.

While enabling the admin module from module list :
"Please note that the administration theme is still set to the rubik theme; consequently, the theme on this page remains unchanged. All non-administrative sections of the site, however, will show the selected fusion_starter_lite theme by default"

i dont understand why i get this "consequently, the theme on this page remains unchanged."

Any help will be appreciated!
thanks...

Comments

ishmael-sanchez’s picture

So does the rubik theme appear on /admin/settings/admin/theme? And on our homepage is the theme fusion_starter_lite? If so this is working as expected. You actually don't even need to enable Rubik on admin/build/themes just set the administration theme at admin/settings/admin/theme and all admin pages should use the rubik theme and other parts of your site which aren't admin pages will use you fusion theme.

jacobson’s picture

Have you tried disabling the core Toolbar module?

timaholt’s picture

I have this same issue on admin 2.0. random updates to a custom module caused the admin theme to not show up at all (or completely intermittently). this module doesn't have any init_theme() functions or anything in it, so i'm not sure what could cause this. Any ideas?

kid_baco’s picture

Did you figure this issue out?

I've recently created a new theme to use as my default and now the Admin option doesn't display. I only see it when I type mysite.com/admin and am in the rubik theme.

I've tried reenabling, resaving, rebuilding (in /admin/settings/admin) all to no avail yet.

kid_baco’s picture

OK, my solution was really simple. I'd just failed to print the $closure variable in page.tpl.php

sja1’s picture

Issue summary: View changes

I had this problem, and it took forever to figure out. I finally traced it back to a call to path_to_theme that was being used in a DEFINE statement at the beginning of a custom module to create a constant containing a path we wanted to reference. It turns out that path_to_theme contains a call to init_theme. My hypothesis is that the DEFINE statement gets called right at the beginning of the bootstrap, before hook_init is called. This means that init_theme is getting called before hook_init thereby setting the theme up before Drupal core gets a chance to do it. Once init_theme has been called once and the theme is set up, subsequent calls to init_theme have no effect.

In any event, the problem was solved by removing the call to path_to_theme from our DEFINE statement.

In addition to path_to_theme, there 4 other functions that call theme_init that could presumably cause the same problem if called before hook_init:

  • block_admin_display_form
  • drupal_render_form
  • _block_rehash
  • theme