I updated block_class from 7.x-1.2 to the latest 7.x-2.3 and now the classes I have added to blocks in the UI are not added to the `$classes` array in any template that implements `block.tpl.php`.

I confirmed that the permission to allow Administrators was checked.

Hacking the module a little bit, I confirmed that every block falls in the "else" even when there are valid classes shown in the UI and on the core block table's css_class column.

    /**
     * Implements theme_preprocess_block().
     *
     * Extend block's classes with any user defined classes.
     */
    function block_class_preprocess_block(&$vars) {
      $block = $vars['block'];
    
      if (!empty($block->css_class)) {
        $classes_array = explode(' ', $block->css_class);
        foreach ($classes_array as $class) {
          $vars['classes_array'][] = drupal_clean_css_identifier($class, array());
        }
      }
      else {
        print "BLOCK CSS IS EMPTY"; //everything is falling into the else
      }
    }

Please see the attached screenshots to confirm if I have everything set up correctly. Updating the code and db from 7.x-1.2 to 7.x-2.3 was seamless with no errors.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wesleymusgrove created an issue. See original summary.

wesleymusgrove’s picture

Issue summary: View changes
wesleymusgrove’s picture

Is this new css_class property on the block variable not compatible with the 7.x-3.6 Context module?

Because when I assign a block to a particular region using the classic Structure > Blocks method and force the "css_tester" block to show up in the sidebar_first region, the `$variables['block']` in `hook_preprocess_block` contains the correct custom css class, which gets correctly written out to the HTML. See attached image block region classic

stdClass Object
(
    [bid] => 11430
    [module] => block
    [delta] => 37
    [theme] => custom_theme
    [status] => 1
    [weight] => 0
    [region] => sidebar_first
    [custom] => 0
    [visibility] => 0
    [pages] => 
    [title] => CSS Tester
    [cache] => -1
    [css_class] => css-tester-block-777
    [subject] => CSS Tester
)

However... when I assign the exact same block to the exact same region using Context, the css_class property does not get added to the `$variables['block']`. See attached image block region context

stdClass Object
(
    [info] => css testing block
    [cache] => -1
    [module] => block
    [delta] => 37
    [bid] => block-37
    [weight] => -8
    [region] => sidebar_first
    [title] => CSS Tester
    [context] => example_context
    [subject] => CSS Tester
)

I rely on Context to assign blocks to regions, so this is kind of a big deal to me. Can anyone reproduce this??

DYdave’s picture

Hi @wesleymusgrove

Thank you very much for your interest in the Block Class module and for posting this Bug report.
Thanks a lot for your great efforts to document this issue with screenshots, data dumps, various test case scenarios, that's really amazing... I think it's the first time I get the chance to answer such a clear and well documented issue (if only we could get more of these and less of the ineffective one liners...).

Alright, straight to the problem:
So, just to clarify a little bit, since the issue summary got me a bit confused:

Based on #3, the problem you're having right now is actually:
"The configured CSS Block Classes don't display when Block is shown through Context" (in this case context-7.x-3.6)

If you don't use Context, after updating from block_class-7.x 1.3 to block_class-7.x 2.3, are you able to display Block CSS classes properly, just by assigning a simple Block to a region?
(I'm trying to isolate the issue)

Since it's not the first time we hear in this issue tracker about potential compatibility issues with the Context module, we made sure it would be tested in code with automated tests.
See test case BlockClassContextTestCase, in block_class.test, line 191.
Following up with this reply, I queued a test on the dispatcher, and I'm not sure if you have access to that, but feel free to take a closer look at the results of block_class-7.x-2.x-dev test with PHP 5.3 & MySQL 5.5, Drupal 7.x:
Tested with:

git,git://git.drupal.org/project/block_class.git,7.x-2.x,sites/all/modules/block_class,1;git,git://git.drupal.org/project/context.git,7.x-3.7,sites/all/modules/context,1;git,git://git.drupal.org/project/ctools.git,7.x-1.9,sites/all/modules/ctools,1;git,git://git.drupal.org/project/features.git,7.x-2.10,sites/all/modules/features,1;git,git://git.drupal.org/project/strongarm.git,7.x-2.0,sites/all/modules/strongarm,1;git,git://git.drupal.org/project/views.git,7.x-3.14,sites/all/modules/views,1;git,git://git.drupal.org/project/features_extra.git,7.x-1.0,sites/all/modules/features_extra,1;git,git://git.drupal.org/project/blockcache_alter.git,7.x-1.0,sites/all/modules/blockcache_alter,1;git,git://git.drupal.org/project/menu_block.git,7.x-2.7,sites/all/modules/menu_block,1;

In particular: context-7.x-3.7

Every test was passed successfully, so I guess I would be pretty confident to say block_class-7.x-2.3 should work fine with context-7.x-3.7.
Maybe you could also try running module's test case on your site, just in case.

Otherwise:

  • Could you be using other Context related modules, such as Context Respect? or any other potentially conflicting modules?
  • Would it be worth a try updating to context-7.x-3.7?
  • Could this have anything to do with a custom template/theme activated through Context? (could be good to potentially test with a standard, simple theme, such as the Core Bartik theme)

I hope this allows us to get a few initial elements narrowed down in order to step forward towards swifly resolving your problem.

Thanks in advance for your reply, testing/reporting, feedback and participation in this module's issue tracker.
Thanks again so much for the screenshots and data dumps.
Cheers!

wesleymusgrove’s picture

I have more testing to do on this issue, but upgrading to context-7.x-3.7 did not resolve it.

Other context related modules that I'm using are:

  • Context as Reaction 7.x-1.1
  • Context Condition Theme 7.x-1.0
  • Context error 7.x-1.0
  • Context Get 7.x-1.2
  • Context layouts 7.x-3.7
  • Context List 7.x-1.1
  • context_list_active 7.x-1.0
  • Context Node 7.x-1.1
  • Context Redirect 7.x-1.0
  • Context UI 7.x-3.7

I am able to assign a simple Block to a region in Structure > Blocks and the css_class works. But it doesn't work when I assign the same block to the same region through Context.

DYdave’s picture

Title: Block class not added to $vars['classes_array'] » [Context]Block class not added to $vars['classes_array']
Component: Code » Compatibility
Related issues: +#1940122: Block Class doesn't work with Context, +#2329563: Block Class doesn't work with Context Respect

Hi @wesleymusgrove,

Thanks again very much for your prompt reply.

Wow!!! You really stocked up on Context related modules :D

According to your tests so far and an issue with Context Respect, previously logged in this tracker (#2329563: Block Class doesn't work with Context Respect), I'd wager, without too much uncertainty that the problem comes from one of the Context related modules...
(see also #1940122: Block Class doesn't work with Context, for narrowing down to "Context related" modules)

I'd say, the modules implementing conditions for Context are less likely to be problematic. The ones implementing actions or displaying blocks are probably more likely to be causing the issue, therefore, I would recommend to start testing these modules first, such as:
(I would start testing and checking these modules first)

  • Context layouts 7.x-3.7
  • Context List 7.x-1.1
  • context_list_active 7.x-1.0
  • Context Node 7.x-1.1

Although, to be perfectly honest, I have probably only really used/tested about 2 of all the modules you listed...

Once again, thank you very much for your feedback on this and we're hoping you will be able to narrow down the problem deep enough to find the culprit and perhaps come up with a patch for related module at some point.

If there's anything else we could to to help, please let us know.
Cheers!

wesleymusgrove’s picture

This isn't a very satisfying fix, but I disabled all those Context related modules (except for Context and Context UI) at the **same time** (not helpful for debugging...I know), cleared all cache, and Block Class started working when assigned to a region via Context. Then I re-enabled all those modules one-by-one (clearing all caches in between) and could not get it to break! Block Class just kept working as expected. Then I disabled them one-by-one (clearing all caches in between) and re-enabled them one-by-one again and Block Class continued to work like a champ. I'm thinking this was just some weird caching issue with my local environment. Sorry to raise such a ruckus and thanks @DYdave for your attention to my issue!

wesleymusgrove’s picture

Actually when I pushed these block class and context module updates to production I realized that the culprit was Context Block Cache Alter 7.x-1.x-dev. Disabling that module fixed the block class issues I was having, which makes sense because that module would have cached off the previous version of the block object before the css class was moved to the block table...or at least that's what I'm going to tell myself so I can get some sleep at night lol.

DYdave’s picture

Title: [Context]Block class not added to $vars['classes_array'] » [Context]Context Block Cache Alter removes Block Class classes
Category: Bug report » Support request
Status: Active » Fixed
Related issues: +#2324341: Block classes removed

Hi @wesleymusgrove,

Thanks a lot for following up on this issue so promptly.

I realized that the culprit was Context Block Cache Alter 7.x-1.x-dev

OMG!! I didn't even know this module existed! :D
Context Block Cache Alter seems pretty experimental... Why am I not suprised there were caching compatibility issues with Block Class :)

Relating to #2324341: Block classes removed and changing issue title.
If you would still be interested in squashing this issue for good, and had some time to spare, you could perhaps take a closer look at #2324341: Block classes removed and ideally come up with a patch.

Otherwise, I'm very happy you were able to fix the problem on your end and found a reasonable potential explanation for the issue.
Once again thank you very much for logging all the results of your numerous tests in this issue (exceptional!), which will allow us to keep narrowing down, with more ease, Context related compatibility support requests in the future.

For now, @wesleymusgrove, I allowed myself to mark this issue as Fixed, but feel free to re-open it, or post a new ticket, at any time if you have any further objections with the solution suggested in this ticket or the related one (we would surely be happy to hear your feedback).

Feel free to let us know if you would have any further comments, questions, issues, suggestions, objections or ideas on this ticket in general, we would certainly be glad to provide more information.
Many thanks in advance to everyone for your reviews, testing, reporting and participation in this module's issue tracker.
Cheers!

Status: Fixed » Closed (fixed)

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

Berdir’s picture

If somoene is debugging missing classes after updating modules, see #2645612: Attributes array doesn't populate classes.