By llaslo on

(4.7) When configuring a block, the other blocks are being reset arbitrarily. At times, only one other block is reset. Other times, all of the blocks get reset. I ended up using phpmyadmin to manually configure the blocks to their original settings. Now I'm hesitant to try to configure blocks any other way. I saw another post about taxonomy-block and this issue, but I'm not using that module.

Has anyone else experienced this?

Comments

llaslo’s picture

llaslo commented

I'm still experiencing this. Anyone else seen it?

spyderpie’s picture

spyderpie commented

and it appears to happen when you Add a Custom Block. Not sure what else may trigger this.

I save my blocks table often, just in case.

Warm Regards,
Julie

spyderpie’s picture

spyderpie commented

But I don't know how to fix ...

When you add a block, it puts your custom block data in the 'boxes' table and should increments the number .. But mine doesn't - it adds it with a BID of 0. And then, it adds it to the 'block' table and sets the delta to the number of that box, in this case 0. It also adds to the 'block' table with only the information that it needs .. very little in fact .. so I identified my new box because I knew it was the only new one I created on the right side. The delta said 0, the number in the 'boxes' table. From there .. I could not see the new block I added in the list, but many of my blocks were reset.

At this point, I could not add another block, because I got a duplicate error in my log file ....

And if I change the value in the boxes table and the blocks table, all is well. But the next block I add has a BID of 0 again. I think this may be a bug .. or I really messed something up in my config. I'll post more if I find anything else out.

spyderpie’s picture

spyderpie commented

I renamed my 'boxes' table to 'boxes_save' and reimported the table from teh database.mysql file ... copy the data back over from the 'boxes_save' table and now everything works fine -- I haven't had the block config change yet.

spyderpie’s picture

spyderpie commented

Something is definately wrong ... it does still reset them .... when I configured the new block for use ..... I spoke too soon .....

llaslo’s picture

llaslo commented

I realize that I took the lazy way out... but for now, it's more important that content in those blocks can get updated than it is for me to fix the drupal glitch, so I'm just making some hack pages for the content manager to update the boxes table when needed. It circumvents having to update or change a block, and it works.

When I have more free time, I'll dig into this.

Drupal still rocks, though, despite little things like this.

spyderpie’s picture

spyderpie commented

By the way - when you are editing your blocks, do you have a 'global' option or do you only see all of the themes listed .. I am curious about that because it appears I am only changing the block settings for a particular theme .. so I am wondering if this might be why the settings change .. maybe I am switching themes and knocking out the settings ...

I opened a ticket -- mine just reset again and it's gonna take me forever to correct it ...

http://drupal.org/node/67844

Julie

Leeteq’s picture

Leeteq commented

And btw, it is by design, and it has certainly advantages that blocks are now per theme, but we need a global setting, so I changed your ticket to a feature request. (http://drupal.org/node/67844)

.
--
( Evaluating the long-term route for Drupal 7.x via BackdropCMS at https://www.CMX.zone )