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

ishmael-sanchez commented

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

jacobson commented

Have you tried disabling the core Toolbar module?

timaholt’s picture

timaholt commented

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

kid_baco commented

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

kid_baco commented

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

sja1’s picture

sja1 commented
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
sickness29’s picture

sickness29 commented
Status: Active » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.

Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.