Wrong theme shown on Administer Blocks page (site building / blocks)

Subscribing.
I described the same issue here:
http://drupal.org/node/293701
I believe this is rather bug, then support request, as it's fairly anoying and not consistent.
Hope someone will fix it in the next release?!

Thanks.

I stumbled on this bug today. I got so annoyed that I wanted to go back to Joomla ;)

But seriously, any news on this bug? It's still there in D6.10

Hi,

today I run into that issue too. After a bit of testing I'm sure, that the combination of some modules causes this bug because I only get it on my developement-server. Nothing to see on my liveserver. Don't ask what module-combination, it could be drush or some cck/views/image modules. I'll try to find out what modules are resonsible for that.

In the screenshot above you can see that my default theme is highlighted but the site looks like garland.

Does noboby can rebuild this or have the same problem? it is impossible to administer the blocks without switching back to the sites default theme in adminmode, edit the blocks and switch back to garland for administration purposes...

some feedback here would be great, thanks...

I've got the same problem today!
a change in the IP could have something to do with that?

that's the only thing different from last friday...also for the Imagecache Profile Pictures module...

any help???

So the problem is about the views module?
but which version? i'm using views 6.x - 2.3
i tried views 2.5 but i got a white sreen when visiting the front page so i reinstalled views 2.3.

does anyone uses views 2.4? is views 2.4 with this same problem above?

i've just installed views 2.4 with no sucess
and with these errors in the front page (now the page appears, not that white screen):

* warning: require_once(./sites/all/modules/views/includes/handlers.inc) [function.require-once]: failed to open stream: No such file or directory in /home//public_html/sites/all/modules/views/views.module on line 512.
* warning: require_once(./sites/all/modules/views/includes/view.inc) [function.require-once]: failed to open stream: No such file or directory in /home//public_html/sites/all/modules/views/views.module on line 512.

Subscribing

i'm using views 6.x-2.6 now, this bug at #10 is gone
but i still can't solve the Admin blocks bug...

any hint?

This is an issue with one of the contributed modules you are using. Try to identify which one, and open an issue against the corresponding module.

I dont know how but the bug is gone now.
I think the update of the problematic module solve it. Maybe we'll never know which module was.

Clarify title.

Solution provided at #13 hence fixed.

FYI

I had this same problem and disabling:
Popups API 6.x-1.3 General dialog creation utilities

It fixed itself

On the site I'm currently working on I found this to be caused by the Hide Submit module (which hides the Submit button after it's clicked, to prevent double-submits).

I disabled Hide Submit on the Blocks admin page, and the problem went away.

I had the same problem. It seems that this is generated by one of the installed modules. It could be one or more.
In my case I solved it by disabling the Popups API module.

I'm having the same problem. In my case i could tracked it to the line (aprox) 235 in block.module that belong to the function _block_rehash, this is the logic flow:
file block.module:
In line 231 the global variable $theme_key is called, wich in my case, points all the time to the current theme, that is to say that if i choose garland as my admin theme (and I DID) the query to the db in the line 235 will deliver blocks for the current theme ONLY and not for the theme that i choosed by clicking on the corresponding tab.
This blocks (with a littlerbit of more processing) will be retreive to admin_display in block and then to the form builder, but what matters is that the theme i clicked on will not have even an entry in the db.

I just did a FRESH installation of Drupal 6.15 in localhost (winxp) and I DONT see the problem, that leads me to think that it has to do with a contributed module.

I found the definitive problem in my case: It was the HOOK_INIT, so if you are experimenting the same problem check if any of the modules you have installed implements this hook and do a littler test.
I just removed it becouse it was in a module developed by me and that was it.

Popups API 6.x-1.3 caused the problem for me. Disabling it worked for me.

Re-closing, since all recent comments were due to contrib modules

I don't think in my case the wrong theme when aministrating blocks has anything to do with any contributed module. I haven't yet enabled any contributed module. On 2 screen i have a wrong theme : - when administrating blocks and on the home screen. For the rest my administration theme is correctly shown. On the 2 mentionned screens i have the default site scheme...What could be the reason ?

nicootje: Everything you're describing is exactly how it's supposed to work.

The administration theme (set at /admin/settings/admin) is the theme used to display administration pages, ie all pages under /admin/, so it won't change your home page. That page and all other non-admin pages will use the default theme selected at /admin/build/themes, unless you use contributed modules to allow more complex theme-switching or allow users to set their own themes.

The one exception to that rule is the blocks administration page, which allows you to configure blocks for each of your enabled themes. When you land on that page it will display the default theme and any changes you make apply only to the default theme. You can change the block configuration for other (enabled) themes by selecting the appropriate theme on that page.

I don't understand why this is marked 'by design.' The original problem is clearly not 'by design', only the late hijack-version.

I ran into this issue with a custom module I was writing. I put a theme() function into the module's hook_init(), and it caused the admin theme to show on the block admin page, instead of the main theme. The theme() function calls up init_theme(), which initializes the theme system and sets the theme variables. And hook_init() runs before block_admin_display(), the menu callback for admin/build/block. When block_admin_display() runs, it is supposed to go to non-default themes when you select theme, and otherwise go to the default theme... except the theme was already set to the admin theme.

From a developer's standpoint, since the theme() function was to do a drupal_add_css(), the solution from my end is probably to put the theme() call in hook_nodeapi() instead, which is called later. (And other developers tempted to use hook_init() for theme functions should take note.) But it does seem to me that this is a flaw with core - that block_admin_display() should not just default to the default theme, but actively use the default theme on the default display's page.

Relevant, related posts:
http://drupal.org/node/594484
http://drupal.org/node/219910
I especially like comment #11: "This is not a bug. Calling theme functions in hook_init() is not supported. Don't do that."

To debug this situation and find what is going wrong :

Add this line to the function init_theme() , inthe includes\themes.inc

/**
 * Initialize the theme system by loading the theme.
 */
function init_theme() {
	watchdog('init_theme', '<pre>'.print_r(debug_backtrace(), 1).'</pre>');
...

The first entry made by this in the watch dog will be the "history" of the php execution until the first init_theme got called.
So the second entry of the array should be the faulty fonction that called the hook!

Good luck !

Same here! Popup API breaks it.
Disabling both

Popups Settings
Scan all pages for popup links.
Do NOT auto-close final message.

solved it for me.

Thanks, that watchdog in init_theme allowed me to find the problem, it was one of my custom modules.

Cheers.

In my case problem was beacause of path_to_theme() call in hook_init.

Same here! Popup API breaks it.
Disabling

Popups Settings
Scan all pages for popup links.

solved it for me.

BUT now my Popups don't POPUP

Yeah, I had the same issue... I added a ticket here with a solution:
http://drupal.org/node/964982

The module http://drupal.org/project/availability_calendars caused it for me, disabling that module resolved it. The issue for this module regarding the problem is here: http://drupal.org/node/1054794

For us we got this bug by doing a drupal_set_message() in hook_init() using the % replacement in the t() function.

Reason this triggers init_theme()

function t($string, $args = array(), $langcode = NULL) {
...
        case '%':
        default:
          // Escaped and placeholder.
          $args[$key] = theme('placeholder', $value);
          break;
...

theme() calls init_theme().

Granted doing a drupal set message on the blocks page is pretty rare, but this does seem like a bug to me; the theme system gets initialized before it should because you use % replacement in the t() function in hook_init.

i'm having this problem after i upgraded from 6.20 to 6.22.

the problem happen with the combination of 4 modules:

- Special Menu Items (http://drupal.org/project/special_menu_items)
- Me (http://drupal.org/project/me)
- Token (http://drupal.org/project/token)
- Real Name (http://drupal.org/project/realname)

i reproduced the error, feel free to test:

http://www.flashmedia.com.br/drupal622/admin/build/block

user: admin
pass: admin

you'll see that the bluemarine theme is active, when the garland theme should be active.

thanks!

As mentioned in http://drupal.org/node/219910#comment-1254086:

This is not a bug. Calling theme functions in hook_init() is not supported.

There are other placeholders to use in t() that will not trigger theme functions, and thus this behaviour.

Otherwise, try to identify the contrib module that is actually causing the behaviour, and file a report there.

Thank you. Hours of searching and this helped in minutes!