Block settings not uniquely set for themes (unless set from default theme)

I too am having this problem. I even tried the cvs version to see if the problem would go away, but no luck. I'm wondering if anyone is NOT having this problem. I know that I've been upgrading my mysql data from 4.6 to 4.7.beta 6 and then to the current final release of 4.7. Seems that somewhere along the way, this problem started and I think it started with the final release of 4.7.

@laura s
Compliments for research & description!

Indeed. Same problem here. As I'm using sections module, I have been mainly looking there; therefore it's good to know that others have the same kind of issue - and it seems like it's not caused by the sections module.

@laura: do you have any news about this problem with 4.7.3 or HEAD?

ok. Thanks!

Closing this. If the problem persists in Drupal 5 it will be reopened.

I am having this problem with the Zen theme. I have several contrib modules running, including taxonomy theme. I have disabled and uninstalled taxonomy theme but the problem persists.

No matter which theme I configure a block for the settings are applied to all other themes.

I am still struggling with this, 2 days now. Heine recommended that I create full fledged themes instead of zen subthemes, and now all have a page.tpl.php and a template.php but the block settings are driving me crazy.

Themes say one thing, but display another. I set the blocks, no updates happen.

I have checked cache, deleted cache, tried everything I could think of with no luck.

Can someone give me a pointer here?

I have built out 8 different sites now to confirm this issue. I am certain that this is still an issue. Can anyone else confirm it? What would someone have me do to in order to provide more information?

At this point, the only way to control block settings is with the default theme. Even then, the settings do not always apply to other themes in the system.

For example:

Theme A is default. Set block 1 to appear on node/1
Theme B is not default. Set block 1 to appear on node/1

Visit node/1 in Theme A and block 1 appears.
Visit node/1 in Theme B and block 1 does not appear.

Another example.

Configure Block 1 in Theme A to have weight of 9.
Visit block settings page for Theme B, and Block 1 has weight of 9.

This should NOT be the case, unless I am mistaken.

I have found this problem to be a very irritating problem. I ran a quick version test with test sites I had running. And this is what I found.
Please not all of these sites were already installed. None of these were tested using a fresh install.

4.7.4.
- Got to admin/blocks
- No themes are listed as secondary local links.
- Go to admin/themes
- Enable more themes. (Only the default was enabled.)
- Go back to admin/blocks
- Now all enabled themes are listed as secondary local tasks.
- When I click on a theme link the sites theme changes to that theme and the block setting for that theme are listed.
- If I change settings for a block, only the selected themes settings change.

5.0
- Go to admin/build/blocks
- All the themes are listed as secondary local tasks.
- Go to admin/build/themes
- Only the default theme was enabled. (Garland)
- Go to admin/build/blocks
- When I click on a theme link, the sites theme does not change to the selected theme and the block settings always show the default theme block settings.

5.1 (All the same as 5.0)
- Then I set the admin theme (admin/settings/admin) to Garland.
- I found that all themes were listed in the dropdown for themes I can set as my admin theme. Not only the enabled modules. (Could be deliberate or a bug)
- Then I set the default them to something other than Garland.
- Then I went back to admin/build/blocks
- No difference, the theme still does not change like in 4.7.4 and the settings are all still the same for every theme.

My conclusion
Clearly 5.x does not work the same way as 4.74, maybe the theme is not suppose to switch in 5.x and that is were the problem comes in.
I did some hacking and when I removed the following lines from theme.inc the theme switched and the settings as well.

  if (isset($theme)) {
    return;
  }

This hack did cause some problems with duplicate functions in template.php files. Almost every theme function in the template.php file that used phptemplate_? Function naming system gave an error, rather than using themes name eg. garland_?. I got the page not to error by rename phptemplate_ to the themes name. But with that there were problems as css files for both themes was being loaded, some of the theme display was incorrect.

The problems with the hack should be ignored it was to highlight the problem. The hack is also not a solution to the problem. Like I said it’s just me hacking at core to see what changes and to learn more of how core works.

The problem I see here is a user logic problem. Should the theme switch to the selected theme when you are editing blocks? I the past with 4.7 I thought this made sense but now with 5.x I don’t think so. Because you can set the display per a block per a theme makes it irrelevant what the path admin/build/blocks looks like in that theme. Doing this like it was in 4.7 also would then clash with the admin theme when that is set.

Also what if a theme was not designed with drupals admin pages in mind. The display of the page might break. I see this with fixed width themes often, this is why I sometimes set garland as my admin theme so I don’t have to worry about the sites theme being compatible with drupals admin pages and thus I can reduce the css my sites users need to download.

I hope to test with 5.x-dev later. If this has been fix in 5.x-dev then I think its time to release 5.2.

... subscribing ...
I'm not having this problem on any of my sites, but it'd like to track this discussion as several users of taxonomy_theme and sections complained about that. I was never really able to reproduce or find a clue. However the problem needs to be solved.

I have just tested this in 6.x-dev and it also seems to have the same problems.

- Lists all themes on admin/build/block page not only the enabled themes.
- Does not display and save block settings per a theme.
- Theme does not change to selected theme even though init_theme() is called in _block_rehash() and block_admin_display() and _block_rehash() is called from in block_admin_display().

I also get an error "warning: Illegal offset type in /path-to-site/includes/theme.inc on line 48."

This problem has been driving me crazy the last few days.
I have also found that when I try to configure a block (e.g. admin/build/block/configure/user/1) it will always show the settings for the current admin theme and not the theme you selected from the list of links at the top of the blocks page.

But I have found a workaround for other admins also have this problem. What I am now using to edit my blocks is the admin theme setting (admin/settings/admin). I change the admin theme to the theme I want to make changes to (e.g. garland) then I go to the relevant theme’s block page (e.g. admin/build/block/list/garland) and I make changes that way. I found that it does not affect the other themes and it shows the correct blocks and settings for that theme. Then when I am done I change my admin theme back to the one I want to use. It’s a pain to do it this way but it works.

Ok I have found the culprit and the way I understand thing it hits at the hart of drupals theme system.

I did a fresh install of drupal 5.1 and 5.x-dev and I struggled to reproduce some of the problems.

The problem of listing all themes on the block page happens after enabling anther theme. It seems like list_themes() does not only return enabled themes. So when the blocks module builds its menu and does not check the theme status then all the themes in the system table will be listed. So that’s a simple fix.

    foreach (list_themes() as $key => $theme) {
      if ($theme->status) {
        $items[] = array(
          'path' => 'admin/build/block/list/'. $key,
          'title' => t('!key settings', array('!key' => $key)),
          'callback' => 'drupal_get_form',
          'callback arguments' => array('block_admin_display', $key),
          'access' => user_access('administer blocks'),
          'type' => $key == $default ? MENU_DEFAULT_LOCAL_TASK : MENU_LOCAL_TASK,
          'weight' => $key == $default ? -10 : 0,
        );
      }
    }

Now for the bigger problem. The problem of the theme not switching when you select a theme on the blocks page. I struggled to reproduce this problem form a fresh install. I compared things to sites that had the problem and started enabling modules. After a while I gave up on that idea. So I then did a backtrace in the init_theme() function and that lead me to the jrating module. But as far as I can see it’s not jrating’s fault. In jrating_menu() it has the following line of code.

drupal_add_js('function rating_postsubmit(nid){' . theme('jrating_postsubmit') . '}', 'inline');

So the problem is the theme() function. The theme function calls theme_get_function() and theme_get_function calls init_theme() and once init_theme has been called its pointless calling it again. So when the blocks page tries to switch the theme it fails because the theme has already been set.

I don’t know how this can be fixed in 5.x as it will require a major change but for D6 I think this needs to be looked at. Now I am no expert but the way I see it there are 2 solutions ether the theme gets set early in the bootstrap and some how modules that want to switch the theme need to do it from a hook or something or it gets set last just before display. Doing it last is difficult, as how do pages get built if you can’t call the theme function.

I have an idea for this, I don’t know if it’s a good idea. But this idea only works if strings are returned with the theme function. The theme function can construct an array of theme calls and instead of return the actual themed data it returns a placeholder for that theme call. So when the page is built all theme functions get called and placeholders are replaced with the themed data. So that way themes can be switched multiple times in the processing and the last theme switch will be the one that is used. The placeholder will have to include all the arguments or the placeholder needs be the key to an array that has all the info for the function call. But it’s a problem if a module creates a theme function that returns something other than a string or if the theme function uses references. Placeholders will also need to be replaced for every variable that is outputted in the page.tpl.php ($head, $styles, $scripts, $content and all block regions …) or maybe some how we can use a Heredoc.

Lists all themes on admin/build/block page not only the enabled themes

Actually this is by design. We once had your if ($theme->status) { ... } line there. The problem is that you are unable to configure blocks for your admin theme as it is not necessarily enabled. The same is true for all disabled themes use by theme switching modules such as sections, taxonomy_theme, ..., so we decided to list all available themes in the block administration. You can easily remove ununsed themes (on file level) completely and your are done. However as this is a crapy solution, we were talking about a different approach (I cant remember or find the issue atm). We could list only themes selected for listing ... for example

$themes_to_list = variable_get('themes_to_list', array());
if (in_array($key, $themes_to_list) { ... }

The variable would contain all enabled themes by default + the selected admin theme. Contributed modules could easily add the themes they use to this list. All other themes would be hidden in block administration. Someone (I think it was drumm) commented this to be a hack with variable_get() stuff. He suggested to introduce a hook to collect all themes that should be listed. AFAIK there never appeared a patch for this and the discussion stoped some time ago.

As for the theme() call. Using drupal_add_js('function rating_postsubmit(nid){' . theme('jrating_postsubmit') . '}', 'inline'); in hook_menu is certainly not the way to go. Is theme_jrating_postsubmit() theme dependant? If not there is no need to use theme() here at all. It can be replaced with a 'usual' function call, e.g. jrating_get_postsubmit() or stg. If it is theme specific, it doesnt make sense here either. Because at this time (hook_menu) were init_theme() has not been called before, you would always get a themed representation for your default theme. What means it IS jrating's fault IMO. Thats how the theme system is designed at the moment ...

I have an idea for this, I don’t know if it’s a good idea. ... The theme function can construct an array of theme calls and instead of return the actual themed data it returns a placeholder for that theme call. So when the page is built all theme functions get called and placeholders are replaced with the themed data.

I havent thought about this much, but at first sight your proposal makes sense. The problem: Code like in your above example (with theme('jrating_postsubmit')) wouldnt work as theme() would no longer return a themed representation. The same is true for all lines that use theme() correctly in a page handler or such. I dont see how this can be solved with a placeholder that is being processed when the page is rendered. 1. This would add a lot of overhead to the theme layer and 2. you would need something like hook_theme_placeholder. If the theme() function returns a placeholder you can no longer work with the themed representation after the theme() call. You can't e.g. modify the output, you cant add stg to it, etc. The only solution for this is to call hook_theme_placeholder when the page is actually rendered, but I think a solution like that will never be considered.

Regarding 'Lists all themes on admin/build/block page not only the enabled themes'. Thats the issue I was talking about: http://drupal.org/node/103717#comment-237850

I seem to have come across a similar problem if not the same problem. I've been using the Sections module to apply Garland to what I felt were administrative pages, the administration theme is also set to Garland, the rest of the site has the system default theme (a custom theme with custom regions). Thus far the Site Building > Blocks page would initially use the system default, which is perfect. All of the sudden it is sticking to Garland. Choosing another theme regardless of whether or not it is active does nothing (the blocks page sticks to "Garland's" settings).

It occurred to me, too, that I could switch the administration theme back to the custom theme, do what I need, and switch back. This is the workaround I'm resorting to indefinitely.

I noticed when switching the admin theme to the custom theme, the blocks page will only use the custom theme regardless of which theme you choose from the secondary tasks.

I have absolutely no idea why this is happening. It seems fairly spontaneous, no additional modules were installed, Sections has nothing to do with this, the themes themselves seem irrelevant.

The only thing I can think of is cron. I hadn't run cron since I set Drupal up and ran it recently on whim. But I have no idea what it is that cron does that would have affected the blocks page let alone if it did.

I think this is the same problem being discussed throughout the thread, however, I'm not in a position to start testing if block settings will be applied universally.

What I was able to dig up in that regard is that I can create a block whilst under the Garland theme, configure which pages it will be visible, then switch to the custom theme and apply it to the region of my choice. However, the configuration of page specifity did not stick even though it was still in there! (The block appeared on all pages!) I had to reconfigure the block and save again. Very peculiar.

At present I don't really have the time to go into this further. Even if I did I'm not sure if I'd even know how to fix this. =\ Just hope this might provide some clues to others and that this problem is still very much present.

Okay this bug should actually be set to critical. For a while I would just create a new block via Garland and edit it further before switching the theme to the custom theme and associating it with the desired custom region. I am not sure what happened, perhaps I accidentally saved while in the build/blocks page, but the site broke completely. I tried tracing my steps and undoing things but even setting the administration theme to the custom theme would still bring up Garland and its settings. All the block settings for the custom theme were lost and the site remained completely broken for about a half hour.

It was unacceptable and downright scary (the client had just sent out an e-mail blast to several thousand people linking to a NYTimes article and the site >_< oh my!). What I wound up doing is going into Garland and giving it the custom regions my custom theme had (via template.php both garland_regions and customtheme_regions), this started placing some blocks in random regions on the site and somehow allowed for the administration theme to reflect properly once again. After that I was able to place blocks in their proper places piece by piece gradually bringing the site back.

=\

But I can't even say for sure if any of the steps I did are what caused the break let alone actually fixed it. The site is in no condition to try and reproduce the errors and fixes. And I don't know how to reproduce the blocks page being broken to begin with.

Hopefully this will help anyone out in the case they run into the same problem as well as possibly motivate someone to investigate further (I really don't have the time! =\ ).

Looks like you ran into http://drupal.org/node/80963

Thanks drumm.

I'm not sure if that is the case.

Two things:

1. http://drupal.org/node/80963#comment-307836

   The original code leaves you without a single block if Drupal dies.

   If she meant for the specific theme there are no blocks then that is not the case. All the blocks still exist.
   On the other hand if she means for the specific theme all the blocks no longer retain their association with their respective region [to respective themes] then yes, that is the case.

2. By default the proper theme is not used for the build/blocks page completely regardless of what themes are enabled/defaulted. The only theme used is the administration theme.

But maybe you're right. Or at least pointing me in a better direction. I'm not really sure.

Thanks though.

I would still consider this critical =\ Both the emergence of the bug and ultimately the site breaking were pretty spontaneous. *cough*someone could lose a job =\

I have also come across the theme() issue on the admin/blocks page. Removing a call to theme() from an in-house module fixed the display issue, and allows the correct theme to be set.

However, when I hit submit on the admin/blocks page the blocks page renders in the default site theme, the page also lists the wrong blocks (site default blocks) whilst still displaying the url and heading for the theme I was editing.

I tracked this down to a similar theme() problem, this time with the views module. After the submit button is clicked drupal calls views_menu which makes (via several other calls) a call to theme().

I added code to block_menu() to ensure the custom_theme is set correctly after the submit button is hit:

global $custom_theme;
  if (! $custom_theme) {
    if (! arg(3)) {      
      $custom_theme = variable_get('default_theme', '0');
    } else if (arg(4)) {
      $custom_theme = arg(4);  
    } else {
      $custom_theme = variable_get('admin_theme', '0');
    }
  }

is there a better solution out there?

Annette

still a problem in 5.5, sigh ... it wasn't happening for a while, but then it came back. perhaps it's indeed triggered by someone calling theme() at the 'wrong' time.

Subscribing, I'm having the same problem with a 5.3 install.

I am having the same issue in 6.4.

The block selections by theme initially worked well with the sections module in place, but themes would not properly switch for the "public, admin, and civicrm" sections I had set up. I then set the admin theme directly which worked for it, but could no longer set the blocks by theme. Even disabling sections did not work. Even a fresh install has not worked!?

GWT

Confirm with gwtardy.
It seems due to this problem that I can't change themes with virtual site module in different sites.

Just confirming I am having this same issue in 6.4. Am looking into modules now to see if any call theme() per #22

Just disabled Rules 6.x beta1 and the problem was fixed

I didn't install Rules 6.x beta1 but the problem still there.

Confirm on Drupal 6.5 - I don't see the links to enabled themes in block position list. It shows only default theme but none from enabled themes.
But I have access to this page by URL: admin/build/block/list/bluemarine

Any fix yet

I have experienced all the issues described in this list at one point or another. There are actually a couple seperate issues and all of them are fixed or do not have anything to do with Drupal core.

Issues:

1. There was a bug in the Drupal update system that is now fixed (in 6.5 I believe). It caused all themes to be disabled. The default theme still works as usual. But as described you will not see the other themes on the block page. You need to go back to the themes page and re-enable them. If you have not updated Drupal core then when you run update.php, your themes will be disabled again and you will have to re-enable them for things to work. Solution upgrade to the newest Drupal core.
2. Many contributed modules have an issue where they incorrectly use a function (I can not remember the exact function at the moment) that will stop the block page from being able to change the theme. Because of this it will only set the settings for the default theme. I like everyone in this list experienced this with D5 and D6 but I assure you that it is an issue with contrubited modules not core as it fuctions perfect on a base install. Solution: disable your contrib modules one by one and test if the problem goes away. Look and see if the module is using hook_init. Many times the culprit function is in there.

Many contributed modules have an issue where they incorrectly use a function (I can not remember the exact function at the moment) that will stop the block page from being able to change the theme. Because of this it will only set the settings for the default theme. I like everyone in this list experienced this with D5 and D6 but I assure you that it is an issue with contrubited modules not core as it fuctions perfect on a base install. Solution: disable your contrib modules one by one and test if the problem goes away. Look and see if the module is using hook_init. Many times the culprit function is in there.

Could you please tell us which function? For some of us it's not really practical to go through disabling and enabling all modules one by one.

90% of the time it is a module that uses a theme related function in hook_init. So if you can grep your module files for _init. I would start with those.

even easier:
use
/devel/reference
from the devel module. So you can just look for *_init

in my case I found the origin and solved the problem by disabling this mod:
drupalforfirebug_preprocess_init

Noticing this issue with the Seven theme as the admin theme. Debugging now.

Problem still presents in Drupal 6.22.
Trying to set up mobile theme but unable to because regions for the default theme take over the blocks page.
I fixed this a few releases of drupal back and haven't had the problem again until today. Have several sites running almost identical configurations but not having he same problem.
Please let me know if anyone else has found a solution for the problem in drupal 6.22