1) If user changes their theme then blocks disappear
2) Changing the theme back the admin/block blocks reappear
3) Each theme in admin/blocks shows the same blocks enabled. Example: for theme1 enabled (user/edit) admin/block will show 2 blocks enabled for each theme. After theme2 is enabled admin/block will show (for each theme) 5 blocks (for example).

It is confusing.

Comments

moshe weitzman’s picture

moshe weitzman commented

Also, there was a report from alaa that when a new theme is enabled, it does not get its enabled blocks properly copied from default theme.

mgcarley’s picture

mgcarley commented

I noticed this in RC1 - was not aware that it was a bug... I thought it was a new (annoying) feature!

he_who_shall_not_be_named’s picture

he_who_shall_not_be_named commented

sorry, but setting doesn't save. Try to change settings change the default theme etc. it is an ugly bug.

gerhard killesreiter’s picture

gerhard killesreiter commented

We need ideas on how to fix this, not complaints on how broken it is.

he_who_shall_not_be_named’s picture

he_who_shall_not_be_named commented

1) Run the sql: "delete from `blocks` WHERE theme not like "your default theme"" any time when you change something in the admin/block page (changes must be made by admin who selected "your default theme" in both of user/edit and admin/themes).
2) I have no idea how to fix the code because (for me and only for me) the 'theme' column has no sense in the blocks table. You know better than me what do you wanted from that.
3) I don't wanted to hurt anyone (sorry if I did that): I posted a bug, that's all.

killes@www.drop.org’s picture

killes@www.drop.org commented
Priority: Critical » Normal

Default theme is pushbutton

1) deleted from blocks as described
2) deleted from system the same
3) went to configure pushbutton blocks and added a block.
4) enabled other standard themes
5) block shows up in pushbutton
6) changed standard theme to chamelon
7) block shows up too.

Marking non-critical

jmiccolis’s picture

jmiccolis commented
Version: 4.7.0-rc2 » 4.7.0-rc3

OK - I'm having some of the same issues. I can't edit block settings independantly for themes. What Killes outlined above works fine, it's when I make a change after that point that things get weird.

8) edit non-default theme, disable all blocks.

9) edit default theme - all blocks are disabled.

If anybody else can reproduce this we should probably mark as critical.

jmiccolis’s picture

jmiccolis commented

After a bunch of digging I've determined that in my case this was a problem with another module - simplenews. I was able to fix the conflict by changing a link in simplenews_menu() from;

theme('add_style', drupal_get_path('module', 'simplenews').'/simplenews.css');

to

theme_add_style(drupal_get_path('module', 'simplenews').'/simplenews.css');

It seems that the theme() function was causing the default theme to be intialized before the block module had a chance to do so for whatever set of blocks I was trying to edit.

moshe weitzman’s picture

moshe weitzman commented

this misuse of theme() is a very common and understandable mistake. we need to clarify this in 4.8. some theme_x functions are not meant to he @themeable and thus should not be run through theme().

killes@www.drop.org’s picture

killes@www.drop.org commented
Version: 4.7.0-rc3 » 4.7.0
Status: Active » Fixed

markign fixed, could not reproduce, contrib involvement.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)