upgrade to 2.2 converts class underscore to dash

I had exactly the same issue. All underscores in the block class field were converted to dashes.

This is a serious problem that will potentially break hundreds of sites on updating. Using drupal_html_class() on end user admins is not good, because it tries to 'adhere to Drupal coding standards' which may differ completely with the standards of the site's administration. Hard-coding a coding standard for a public product is a very selfish and stupid idea. Custom block classes should not be subjugated to coding standards because this will only lead to people hacking the module to get rid of this garbage making them stop receiving security updates.

Underscores are a perfectly valid symbol in CSS identifier names that cause no harm whatsoever and it should be up to the end user to decide whether to use them or not. Please replace all instances of drupal_html_class() in the newest version with something else, like a function of your own.

https://api.drupal.org/api/drupal/includes!common.inc/function/drupal_ht...
https://api.drupal.org/api/drupal/includes!common.inc/function/drupal_cl...

Possible patch:

@@ -32,7 +32,7 @@ function block_class_preprocess_block(&$vars) {
   if (!empty($block->css_class)) {
     $classes_array = explode(' ', $block->css_class);
     foreach ($classes_array as $class) {
-      $vars['classes_array'][] = drupal_html_class($class);
+      $vars['classes_array'][] = drupal_clean_css_identifier($class, array('/' => '-', '[' => '-', ']' => ''));
     }
   }
 }

(Something went wrong with my first comment - trying again)

Instead of calling drupal_html_class($class), this module should use drupal_clean_css_identifier($class, array('/' => '-', '[' => '-', ']' => '')).

I completely agree with caspianroach - I was appalled yesterday when I ran the update on a couple of dev sites, and it broke my headers & logos because I used underscores in the class name. That would mean me modifying the CSS in 70+ sites in our multisite - this is not a good fix. Please revert this!!

Totally agree with the above. Even though this is a small module, I am glad I tested this locally first! ^^
And I would think that such a change should require a new major version with proper warning and documentation... not a minor one, especially a security one.

Agreed, the security fix is too disruptive and will be breaking sites across the interwebs today. I'm going to invest a little time in an alternative patch now. If the module maintainer agrees that the security release needs a revision, we should do it asap.

It seems to convert upper case letters to lower case, that breaks styles, too..

drupal_html_class goes beyond security sanitization to create class names observing drupal coding standards. While we all love drupal coding standards, they should not start getting enforced as part of a security patch at the cost of breaking everyone's site.

Attached are patches against 2.1 (pre-security update) and 2.2 (post securitiy update) that simply sanitize the class names for security, and do not force them to conform to drupal's coding standards. Hopefully these get committed.

I should mention, if you are having issues with the security fix and the patch works, please comment here and/or mark the issue "Reviewed and tested by the community"

Hmm, reroll against HEAD?

@cfm4n (#6) I completely agree with you and this is a problem.

Reviewed the patch and it makes sense. Also tested #14 and it applies cleanly and functions correctly.

Should get a new version out there as soon as possible, since I'm sure quite a few people impacted by this!

Thanks guys, totally didn't know drupal_html_class() was that aggresive!