blocks cannot be configure if administration theme used

I'll take a look at the code that saves the settings. I suspect that the place it is getting the current theme from is returning the administration theme, or nothing at all.

We could add the current theme name to the form_state, if necessary.

I can't recreate this. I set Minnelli as the admin theme and Garland as the main.

Inside the block config page Garland (main) is presented by default. Whatever regions I configure there shows outside the admin pages as expected.

I could be misunderstanding the problem. Arancaytar, you can recreate this?

I am unable to reproduce this (tried Deco and PushButton as site themes, with Garland as the Administration theme).

When I go to the Blocks configuration, it defaults to showing me the system theme. Any changes I made to those blocks is then correctly saved and shows when I return to the home page. I was also able to select and modify the blocks for any other enabled theme by choosing that theme name from the list at the top of the page.

@Arancaytar: Did you reproduce the issue?

(cross-posted with dvessel)

Tested:

1.) Site has default theme 'garland'.
2.) Visited /admin/build/block, changed settings successfully.
3.) Set administration theme to 'pushbutton'.
4.) Visited /admin/build/block, it opens to the main theme (not the admin theme).
5.) Changed blocks for the main theme by dragging the navigation block to the other sidebar.
6.) Visited /.

Result: The change from 5.) is reflected just as it should.

Can you tell me if (and how) your steps differed from mine? As it stands now, I haven't been able to reproduce this.

Cross-posted with dvessel and scoutbaker - I blindly dove into the code rather than try to reproduce first. ;)

So it seems this bug is caused by something other than admin theme, as it is not possible to reproduce like this.

Heh, one step at a time. ;-)

mariuss, *three* of us could not reproduce it. It could be some edge case so give as much information as possible. Is this a fresh install or update? Did you run the db update scripts? Whatever you think is relevant, please list them.

@mariuss: The entire design of Drupal is based on providing a framework for contrib modules to be able to integrate with and modify the core functionality. That's how they're able to add additional features.

The problem is that the Teleport module (which I maintain) has a hook_init() that calls drupal_get_form(). For some reason, calling a theme function in the hook_init stage causes the global $theme variables to be set to the admin theme rather than the actual theme, which interferes with the block admin page.

I would call this a bug in the theme system, because it's not mentioned anywhere that you can't safely call theme functions from hook_init. I do need to call drupal_get_form() on every page, and I'm not sure how to do that without putting the call into hook_init.

An appropriate issue, possibly just against the documentation, needs to be opened. From incidentist's description, there is not an issue with the block module. It also doesn't qualify as critical.

It seems that incidentist would be the best one to open an appropriate issue. This one is resolved.

Done. See #219910: Calling theme function from hook_init() interferes with administration theme. I hope it's not brushed aside as a documentation problem, since it's not completely loony to want to pass themed content to a javascript that appears on every page.

Hello,
Have the same problem. Using D5.7. The cause is Advanced Forum.

I am having this problem as well using a custom theme. No idea what module is causing it... anyway to find out w/o manually turning on/off all of my modules?

I was having this problem as well and (thanks to this thread) found out that it was caused by calling a theme function from an init hook: #219910: Calling theme function from hook_init() interferes with administration theme.

See #553944: Define hook_menu_get_item_alter() as a reliable hook that runs before the page is doomed for a patch that would fix this problem in D7 (but the approach taken there is too big of a change to be backported to D6, unfortunately).

I'm having the same problem with zen(main theme) and garland (admin theme)

soo now i get to look for hook_init in all the modules i have enabled to see if one of them is causing this?

subscribe

subscribe...happening on many of my sites, although it is hard to track down the exact instances where it happens. if i find anything i'll post back.

Same problem here using Garland for admin and my own theme for front, modules don't seem to have any effect.

e: oops, didn't mean to change the version on the whole ticket... not sure what the protocol is on that. I'm using the latest stable (6.19).
ee: I figured out which theme vars I needed to add in order to see the controls, but the fact that it still displays that ONE admin page with the broken theme that I've just started working on is utterly ridiculous. Usability 101: if you come to a fork in the road, make a damn toggle switch.

same here

Work Around for Some

I used this work-around to "fix" this issue for a specific module I worked on. If you have this problem you may be able to do something similar; as a work around. I am curious to know if there are any reasons you should not do this, however, I am satisfied with this as a solution for my specific situation.

I followed this tutorial as well as the follow up to build an ajax_view module. Because I have a separate admin theme the blocks interface no longer gave me access to my theme's blocks (see comments).

Code that produced the issue:
in ajax_view.module

function ajax_view_init() {
    theme('ajax_view_javascript');
 }
 
function theme_ajax_view_javascript() {
    drupal_add_js(drupal_get_path('module', 'ajax_view') . '/ajax_view.js');
}

My work around:

function ajax_view_init() {
  //theme('ajax_view_javascript');
  drupal_add_js(drupal_get_path('module', 'ajax_view') . '/ajax_view.js');
  /* Calling drupal_add_js directly prevents issues with the hook_init() and theme()
     functions which prevents loading an alternate themes block interface. */
}

I do not know if this there are any negative side effects from doing this. I do know that the module functions correctly, a view is loaded dynamically and displays correctly.

My particular view makes heavy use of the theming engine, there are template files which control the page, rows, and fields. Needless to say I was very happy that this change allowed my version of the module to work without interfering with the blocks interface.

What I'm finding is that in system.module on line 536 we have:

$custom_theme = variable_get('admin_theme', '0');

Which is fine except that it's a global variable that is also used by block.admin.inc in all of the block theming functions. And what that means is that system_init() sets $custom_theme to the admin_theme variable and the block module never seems to change it to the appropriate theme for building theme regions and block assignments.

My solution sucks but it's the only thing I have done that works for me. I change the above code to make sure we're not on the block admin page before setting $custom_theme to the admin_theme:

if(arg(2) != 'block') $custom_theme = variable_get('admin_theme', '0');

I've tried several other things such as changing the $GLOBALS['custom_theme'] and $GLOBALS['conf']['admin_theme'] variables if I'm on the block admin page and nothing else works. None of the modules I have installed have any theming functions called in their hook_init() either so I have no idea why this started happening.

Turns out my problem was a javascript error.