Jon Saints wrote:
I notice a bug in D6.4 and CVS in the block module. This post, however, is not to report the bug (i will use bug tracker for that). This post is to ask a development question that will help me create a patch for the issue.
On our website we use different themes for different sections of the site. As the user browses to different sections of the site, the theme is changed automatically by changing $custom_theme global in hook_init().
Bug background: The bug occurs when administering blocks. For example, if my current active theme is foo_theme and I click admin/build/block/list/bar_theme a list of blocks for bar_theme is not displayed. Instead, a list of blocks for the active theme foo_theme is displayed. When the user clicks the link "Bar theme" they could reasonably expect that a list of the blocks for bar_theme should display.
The development question: I think the bug has something to do with the code in the block module function block_admin_display(). In this function the author of the code tries to display a list of blocks for the theme the user selected by changing the global variable $custom_theme. The problem with this approach is that outside of hook_init() I have found that changing $custom_theme variable has no effect on changing the active theme.
Have others found this to be the case that changes to $custom_theme variable have no effect on changing the active theme outside of hook_init()?
If this is the case then we need to rethink how we are pulling the list of blocks in the block module admin.
Thanks Jon
$custom_theme takes effect as soon as init_theme() is run. The later in the page that you set it, the more likely that init_theme() will already have run. That makes it definitely work best inside hook_init(), but often later is ok, as long as some module isn't calling theme(...) very early. Calling theme() functions in hook_init(), for example, could be very bad as it can destroy $custom_theme setting.