Somehow the form must be wrongly defined. I have some blocks in my page, and when I assign a class to one block, other blocks get the same class automatically assigned. Somehow all of them share the same form input box.

Comments

Todd Nienkerk’s picture

Are all of the blocks you're referring to custom-defined? Are any of them defined by modules? If so, which modules?

Do *all* of the blocks have the class mistakenly assigned to them? If not, which ones do, and which ones don't? Do you see any kind of pattern in the behavior?

Farreres’s picture

What I could see is that if I assigned a class to one block, another got the same class assigned. Then, if I removed the class from the wrong block, it was removed from them all. Thus, somehow there is only one form shared by all of them. There must be some error in the form definition. But I am not an expert programmer in this area, little help here. I am sure you can find the case yourself too. I think it has happened me with some views-generated block and remember I cloned some views for speeding development. You could check if this has anything to do with the problem.

Todd Nienkerk’s picture

Title: Class in one block affecting other blocks » Class in one Views-generated block affecting other Views-generated blocks

I have confirmed that this happens for all Views-generated blocks. In fact, this problem appears to occur for any module-generated block that does not have a numeric delta value. That is, if the blocks defined by a module have text as delta values, the CSS class associated with one block will appear for all blocks generated by that module.

I'm almost positive this is due to the type of data defined by the .install file when the module's DB table is created:

      db_query('CREATE TABLE IF NOT EXISTS {block_class} (
          `module` varchar(50) NOT NULL,
          `delta` int(11) NOT NULL,
          `css_class` varchar(50) NOT NULL,
          PRIMARY KEY  (`module`,`delta`)
        ) ENGINE=InnoDB DEFAULT CHARSET=utf8;');

As you can see, the delta column is expecting an integer, not a string.

I will forward this bug to someone who has more experience with databases than I.

Robbie Sternenberg’s picture

Assigned: Unassigned » Robbie Sternenberg

Assigning to self.

Todd Nienkerk’s picture

Assigned: Robbie Sternenberg » Unassigned
Status: Active » Fixed

Fixed in version 5.x-1.0, which will be available in just a few minutes.

achute’s picture

Version: 5.x-1.0-rc » 5.x-1.0

I just installed 5.x-1.0 and it appears to have the same problem as mentioned above. I have two blocks provided by Views in my right sidebar. If I add a CSS class (ie: xxxalert) to one block, it applies it to both my blocks. If I edit the 2nd block, I see the CSS class entered in the text field even though I never added it specifically to that block. If I delete the class (from either block's config), it is removed from both blocks.

I'm on Drupal 5.7. Let me know if you need more details.

-ac

Todd Nienkerk’s picture

Status: Fixed » Active

Re-opening issue to fix install hook.

Robbie Sternenberg’s picture

Assigned: Unassigned » Robbie Sternenberg

Re-assigning to self.

Todd Nienkerk’s picture

Status: Active » Fixed

Fixed in version 5.x-1.1. Thanks for staying on top of this, everyone.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.