Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The global variables $custom_theme, $theme_key, and $theme don't get any useful value ($custom_theme is usually set to 0) until I don't call init_theme().
That means that if any modules call drupal_add_css() passing a different $path argument basing on the current theme, they would not be able to pass the right argument.
init_theme() cannot be called in pages like admin/build/block/list/zen_classic as that would force the pages to be rendered with the site theme.
Comments
Comment #1
avpadernoI noticed that only during inside an implementation of
hook_footer()those variables get any useful value; is that the wanted behavior?Thanks for any help.
Comment #2
ainigma32 commentedI don't know what those global variables are used for but why would you want to base the $path argument on the current theme? What are you trying to accomplish by doing that?
- Arie
Comment #3
avpadernoSuppose a module needs to use different CSS files basing on the current theme, and suppose that the name of the file is based on the name of the current theme. The global variables can be used for this purpose, if they would be initialized on the right moment.
$theme_key, and$themeshould contain the name of the active theme, while$custom_themecontains the name of the custom theme which overrides the default theme. The last variable should contain the name of the theme currently used for the page being shown, which could be different from the default theme selected for the other pages; this happens, i.e., when the administration theme is set to a different one used for the Drupal normal content, or when the theme used for the editing pages is different from the default.Actually, there is a module which uses that variables, but not being set to a useful value, it cannot work.
Comment #4
avpadernoComment #5
ainigma32 commentedHave you read this thread http://lists-new.drupal.org/pipermail/development/2008-August/030883.html on the developers mailing list?
- Arie
Comment #6
avpadernoThe topic there is different from what I am asking.
Comment #7
dave reidI have noticed this problem too when using theme_get_setting() in 6.x-dev. The global $theme is undefined and the function call fails.
Comment #8
avpadernoThe only way to get any value from those global variables is to implement
hook_footer().I think this is the only case of Drupal global variables which get initialized in a particular moment, while the others get the same value from when Drupal bootstraps until it shuts down.
Comment #9
ainigma32 commentedOk so you determined that the behavior you are seeing is 'by design' but you would like to see it differently right?
Maybe you could start proposing the way you think it should work? Who knows; it might eventually make it into core.
- Arie
Comment #10
avpadernoI just pointed out this because to me it seemed wrong; I also wanted to see if somebody else thought it would be implemented differently.
I didn't used the feature request category because I am sure it would be immediately set to won't fix.
The active (needs more info) status is thought to be used by the maintainers of the project.
Comment #11
ainigma32 commentedNot sure what you mean by that but if you would like to keep this support request in the active state; be my guest :-)
I just thought you might get some more input if you actually propose the way you would like to see it implemented.
- Arie
Comment #12
avpadernoI mean that you keep to set the status to active (needs more info); that status is thought to be used by the maintainers of the project (in this case Drupal) when they want to have more informations about the report, not from any other user who reads the report.
I could also open a feature request to ask that those global variables get initialized earlier than now, but I am pretty sure it would be set to won't fix, or by design.
I simply hoped that somebody would explain at least why this happens, and why this must be implemented like it is now.
Comment #13
ainigma32 commentedWell I guess that's a discussion that belongs here http://drupal.org/node/171350 but I disagree that Drupal maintainers are the only ones that are supposed to set Drupal issues to active (needs more info)
Those guys (and girls) are busy enough as it is...
I'm well aware it can be quite frustrating when you post a valid question and nobody seems to be willing to answer.
I would suggest you do try to post a feature request. Even it is set to won't fix or by design (theoretically) you will have gotten an answer as to why this is implemented the way it is.
Good luck!
- Arie
Comment #14
damien tournoud commentedThis is by design.
Comment #15
oxford-dev commentedI would like to re-open this issue because if this is by design then it can cause trouble with a site.
I have an issue whereby under certain conditions pages do not render at all or render incorrectly because $theme = null when init_theme is called during page render.
What I've learnt of the problem so far:
*It seems to be server specific (works fine on one server but fails on all others).
*When accessing update.php, the page is a horrible hybrid on my theme and the garland theme. This is because it is trying plug and the content from my custom theme (css, js, regions etc) into the garland maintenance page template. This can be traced to inti_theme where $theme = null (it therefore searches for a custom theme).
*After running update.php all pages with views results get a WSOD, this can be traced to init_theme where $theme = null.
*At anypoint if these errors start occuring, by going to admin/build/themes and clicking 'save'. The problem is temporarily resolved.
I need to trace when $theme is being set as a global variable and figure out why it isnt being set correctly.
This has really be wracking my brain! Please help!