Drupal 7.14
Context 7.x-3.0-beta3

Blocks placed through Context do not have the block class.

Comments

alex_wang’s picture

Status: Active » Closed (works as designed)

Hi leex,
I have tested Block class module with context,
All work well for me.

dydave’s picture

Hi leex and alex_wang,

@alex_wang:
Thanks a lot for testing this issue and I'm really glad to hear there is actually no problem with context.

I would have been pretty surprised there would be any issue, since the 7.x-2.x branch actually works on leveraging block_load, which I would assume would also be used by the Context module.
Thanks a lot for your cooperation and help to take a little bit of time to test this during our March 2013 Shanghai Workshop while I was carrying training with others.

@leex:
Feel free to re-open it, or post a new ticket, at any time if you have any further objections or encounter any other issues, we would certainly be glad to take a closer look.

Please let me know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on any of these commits or this ticket in general, I would be glad to provide more information or explain in more details.

Thanks again to everyone for your help, reviews, feedback and comments on this issue.
Cheers!

jdanthinne’s picture

Status: Closed (works as designed) » Active

Using Context 7.x-3.0-beta6, I confirm there's no block class outputted when adding a block from within a context.

dydave’s picture

Hi jdanthinne,

Thanks a lot for following up with this issue.

I have just tested with a Shopping Cart block (Drupal Commerce), Core Search block and a custom block, with Context 7.x-3.0-beta6 and Block Class 7.x-2.0 and 7.x-2.x-dev, in all cases everything seemed to work as expected: classes would display correctly.
I have created a simple context to display the block in sidebar second (Bartik theme) on the front page.

I think we're going to need much more information than that.

  • Would you have changed anything to the template files? tpl.php files, template.php, etc....
  • Could you please provide more detailed information on all versions? (Drupal Core version as well)
  • Could you please make sure you run the update script if you updated from 1.x?
  • Could you please double check if everything is in order when you display the blocks without Context?
  • Could you please try testing with the Core Search bock and a Custom added block?

Ideally, a screenshot could help as well.

I would certainly be glad to look further into this issue, but currently, I am unable to reproduce the problem.

We would greatly appreciate if you could provide more detailed information on this issue.
Thanks very much in advance.

mishac’s picture

I'm having this problem too.

  • Using default block.tpl.php and nothing block related in my template.php
  • Drupal 7.20
  • block_class 7.x-2.0
  • Context 7.x-3.0-beta6
  • Tried with core blocks, custom blocks, and views blocks
  • Works fine on blocks not displayed with context

Edit: and JUST now that I posted that I checked again and it's working. Sorry to waste anyone's time!

dydave’s picture

Hi mishac,

Thanks a lot for your feedback and detailed follow up on this issue.

With the setup described at #4 (block_class-7.x-2.x installed, working with context-7.x-3.0-beta6 on D7.19) , I tried uninstalling block_class completely.
Then, I re-enabled it again and indeed, I was able to reproduce this bug.

Solution: I tried flushing the cache and the classes appeared again.

If you or anybody encounter this issue, could you please try flushing the cache and let us know if it works for you or not?

If that's the case, we might have to add a bit of code to flush some cache (context or cache_block, in this case, I guess) when module is enabled.

I would greatly appreciate to have your further feedback, reviews and testing on this issue, since it seems it has already been encountered multiple times.

Feel free to let me know if you would have any particular questions, comments, concerns or suggestions on any aspects of this ticket, I would certainly be glad to provide more information.

any further feedback, testing, comments, questions or reviews would be highly appreciated.
Thanks very much to all in advance.
Cheers!

mishac’s picture

I found that the issue reoccurs whenever I save a block with a new class, but then after a refresh it's fine. Is this the same caching issue you're talking about?

retrodans’s picture

Just to note I appear to be having the same issue on a local environment. Got lots of modules setup, but have tested with both garland/omega themes.

block_class : 7.x-2.0
context : 7.x-3.0-beta2

When I insert the user switch block using regular blocks UI it works fine, adding my custom class. When I remove it and instead add using context, the class is inserted as expected.

If there is anything I can do to help diagnose and test, please do let me know and I will try to give things a go.

Dan

dydave’s picture

Hi guys,

Thanks a lot for following up on this issue.
Just wanted to let you know that unfortunately, I didn't have much time these past few days to look into this issue in detail.

Therefore, @retrodans, I would certainly greatly appreciate if you would have some time to spend on this to try to diagnose what's going on with the context.
It seems there is some caching issues somewhere, related with Context and blocks.
I would greatly appreciate if you could take some time to try testing a bit further in order to isolate where the problem could come from.

Not to mention that patches would also be greatly appreciated.

I will try to get back to this issue this week when I have time, but I'm not sure exactly when, so if you could potentially start testing/diagnosing the issue, it would certainly save me some time if I need to write a patch to fix it.

Feel free to let me know if you would have any questions, comments, issues, concerns, ideas, or suggestions on this issues, I would surely be glad to provide more information or explain in further details.

Any testing, reviews, patching, comments, suggestions or objections would be highly appreciated.
Thanks very much to all in advance for your help.
Cheers!

retrodans’s picture

Okay, well that was quick. Got into the office and ran a fresh install to look into this. It appears the newest beta version of context (7.x-3.0-beta6) no longer has this issue. I reverted to same version as previous post, and the issue returned. I then upgraded again, and all appeared fine for me with block class.

So, I now have the classes appearing, the only issue still there is that if I edit a class, I need to 'drush cc all' to have it appear (none of the other cache options will purge the class change).

Dan

dydave’s picture

@retrodans
Thank you so much!

I need to 'drush cc all' to have it appear (none of the other cache options will purge the class change)

This is kind of annoying.... it seems we would need to flush all?
Maybe we would need to flush all entries in the cache table related with context (cache table, cid:context), what do you think?

I would greatly appreciate, once again, if you could take a try on that:
Most likely you would have to add a call to cache_clear_all('context') to the function block_class_form_submit, in block_class.module around line 85.

In a dream world, this solution would work and you could submit a patch, which would pretty much solve this issue.
We would then let others test the patch with a "testing" period of 2 weeks and if no further issues would be reported, I would be committing and granting you authorship on this patch.

In any case, thank you so much for your time, work and efforts on this @retrodans, it is certainly highly appreciated.

Feel free to let me know if you would have any other questions, comments or concerns on this issue, I would surely be happy to provide more information or explain in more details.

Any further testing, reviews, feedback, comments, questions, recommendations or objections would be greatly appreciated.
Thanks very much to all in advance.
Cheers!

retrodans’s picture

StatusFileSize
new823 bytes

Ok, have done some work, took a bit of tweaking, but think I have the right cache clear query now (after confirming context is installed for the sake of performance and tidiness)

if(module_exists('context')){
  cache_clear_all('context', 'cache', TRUE);
}

To create the patch I ran:

Appears to work on my local copy at work, but will run against a seperate copy tonight at home.

Dan

retrodans’s picture

Ok, got home, ran in the patch, upgraded context, ran update.php, and cleared the cache. Not sure why I had to do the update.php run, but it appeared to resolve any final issues I was having locally.

All seems good for me now.

Dan

dydave’s picture

@retrodans:
Thank you so much for taking the time to make a patch and test it (we do really live in a dream world! :-)).

I would like to sincerely thank you for having taken the time to document a little bit how the patch was created and providing more information about the code changes you made.

The patch looks good, just a quick comment though:
I think the call to cache_clear_all (along the code you added) should probably be after the db_update.
So basically just moving the added code right after the db_update, what do you think?

If you could re-roll with the suggested change (submit the revised patch) and change the status of this ticket to needs review (to trigger the test bot), then we would be pretty much wrapped up with the work and awaiting feedback from others for a little while.

Once again, thanks a lot for your great help on this, you really saved me so much time.
Cheers!

dydave’s picture

Status: Active » Needs work

Now we've got a patch and I have requested for a small revision, it makes sense to change the status to needs work.

Thanks in advance to all for your testing, reviews, comments and reporting.
Cheers!

retrodans’s picture

Status: Needs work » Needs review
StatusFileSize
new468 bytes

Okay, I have made the change, makes sense to me as if the site is popular, the page would get recached again before the DB has been updated, thanks for the comment.

Have set the post to needs review now and the new patch is attached. Hope this helps others.

Dan

Status: Needs review » Needs work

The last submitted patch, block_class-contextcachefix-1940122-16.patch, failed testing.

dydave’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
Status: Needs work » Needs review
dydave’s picture

dydave’s picture

Thanks a lot @retrodans!

I had to change the version of the ticket to re-test the patch and it applied nicely, as expected.

Patch looks good to me, I have tested and it seems to be working as expected.

Let's wait for a little while (at least 2 weeks) to try to get some feedback, reviews and testing, then hopefully, we should be able to get that committed.

Once again, you really saved me quite some time on this, since I have been kept really busy lately and this seemed to be a rather major/critical issue.

Any further questions, feedback, issues, comments, reviews, testing, objections, suggestions on the patch or this issue in general, would be highly appreciated.

Thanks very much to all in advance for your feedback, testing, reviews and reporting.
Cheers!

retrodans’s picture

Anything I can do to help further on this? Notice it's been a couple of weeks, so just let me know if you need me to have a look into any tweaks for this patch.

Dan

dydave’s picture

Status: Needs review » Fixed

Thanks very much @retrodans for your kind follow up and keeping an eye on this issue.

After two weeks, with no updates on this ticket, no other objections, comments or replies, I went ahead and got it committed against the 7.x-2.x branch at c2bb84a.

I allowed myself to mark this issue as fixed for now, but feel free to re-open it, or post a new ticket, at any time if you have any further objections with this patch (we would surely be happy to hear your feedback).

Please let me know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on any aspects in the commits or this ticket in general, I would be glad to provide more information or explain in more details.

Special thanks to @retrodans for the great work and help on this issue.
Thanks again to everyone for your help, reviews, feedback and comments on this issue.
Cheers!

Status: Fixed » Closed (fixed)

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

dydave’s picture

Hi guys,

I wanted to quickly get back to this issue, since we have been adding automated Test Cases to the module (see #2060319: Improve and document block_class.test) and thought that we might also want to get this issue tested in code.

So I added a new Test Case called BlockClassContextTestCase to the module, which was actually quite practical to add as it could extend the BlockClassUpdateDisplayTestCase Test Case Class which updates and checks if Block CSS class displays as expected.

All we have to do is include the context and ctools modules as dependencies and save a Test Context with a block for which the classes should be updated and checked.
In this particular case, a very simple Context was used, which was actually created manually through the interface and then exported, but in short:

  • Conditions: Display only on front page.
    <?php
        $context->conditions = array(
          'path' => array(
            'values' => array(
              '<front>' => '<front>',
            ),
          ),
        );
    ?>
    

     

  • Reactions: Display the Who's online block at the top of the content region.
    <?php
        $context->reactions = array(
          'block' => array(
            'blocks' => array(
              'user-online' => array(
                'module' => 'user',
                'delta' => 'online',
                'region' => 'content',
                'weight' => '-10',
              ),
            ),
          ),
        );
    ?>
    

I thought the Who's online block would be a suitable candidate for this test with Context, since by default it is disabled/hidden (unlike the Main page content block).

Once the configurations for the Context and Test Block (in this case Who's online) are in place the tests are the same as for BlockClassUpdateDisplayTestCase::testUpdateDisplayClass (Block CSS class update and display Test Case).

I tried to disable/comment the lines 95 to 97 in block_class.module (code/patch from this issue, see #22) to run the tests and they failed for the Block Class Integration with Context Test Case, which is a very good sign that this patch was certainly needed.
 

Therefore, I went ahead and committed the changes against the 7.x-2.x branch at afa298e, followed by a minor commit at c4bc43e to fix a white space I missed that was reported by PAReview.sh.
The changes were back-ported to the 7.x-1.x branch at 09dfc5b.

I invite you to check the Tests results at anytime for any of the versions on the Block Class Automated Testing page.

Feel free to re-open this issue, or post a new ticket, at any time if you have any further objections with this update/change or any of the related commits (afa298e, c4bc43e, 09dfc5b - we would surely be happy to hear your feedback).

Please let me know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on any of these commits or this ticket in general, I would be glad to provide more information or explain in more details.

Thanks again to everyone for your help, reviews, feedback and comments on this issue.
Cheers!

lahode’s picture

Status: Closed (fixed) » Active

Hi guys,

I had a problem with my right sidebars and Context. I did apply all your patches, cleared cache and went deaply into the code in order to understand why the css_class was not attached to the block object.

Finally a friend of mine found a hook that solved the problem. I think it is worth having a look and put it into block_class.module, I let you decide.

Cheers

/**
 * Implements hook_context_block_info_alter().
 */
function block_class_context_block_info_alter(&$block_info) {
  $theme_key = variable_get('theme_default', 'garland');
  $result = db_select('block')
    ->fields('block', array('module', 'delta', 'css_class'))
    ->condition('theme', $theme_key)
    ->execute();
  foreach ($result as $row) {
    if (isset($block_info["{$row->module}-{$row->delta}"])) {
      $block_info["{$row->module}-{$row->delta}"]->css_class =  $row->css_class;
    }
  }
}
dydave’s picture

Issue summary: View changes

Hi @lahode,

Thanks for getting back on this issue related with Context and sorry for the late reply.
Actually the integration between Context and Block Class is currently automatically tested sucessfully from code (see related test case in block_class.test).

Although, the Test Case is very basic and for a very simple case, I haven't encountered any issues while using recent versions of Block Class and Context for more complex cases. Additonnally, it seems it has been quite a while (8 months) without having any users reporting issues related with Context.
Therefore, I'm not completely sure I understand why this hook would be needed and would probably need more details. I'm assuming perhaps something else could have caused this issue in your particular case.

  • Have you tried testing with the latest versions of Context and Block Class?
  • Could the issue come from the theme? or theme override functions (such as THEME_preprocess_block)?
  • Could you please provide a dump/export of the Context?

It would be greatly appreciated if you could perhaps provide some debugging information from the theme level, for example printing (dpm with devel) the $vars['block'] variable from a THEME_preprocess_block function implementation.

Please let me know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on this ticket in general, I would be glad to provide more information or explain in more details.

In any case thanks very much for posting back and contributing this code snippet.
Cheers!

michaelschutz’s picture

Hi - I'm brand new to Block Class, just testing it out last night, and was having this issue too, until I disabled the Context Respect module during troubleshooting. It seems as though there's something with Context Respect that's preventing the classes from appearing. I'm sorry I don't have the ability to walk through code to try to troubleshoot, but I just thought I'd mention it in case someone else continues to have the issue and may be attributing it to Context when it might be another helper module causing the problem.

Latest stable versions of Block Class, Context, Bootstrap, and Context Respect.

david_garcia’s picture

Yes, CONTEXT RESPECT breaks block_class module.

Issue reported and patched there:

https://www.drupal.org/node/2217553#comment-9098371

Greetings!

david_garcia’s picture

Title: Block Class doesn't work with Context » Block Class doesn't work with Context / Context Respect
dydave’s picture

Title: Block Class doesn't work with Context / Context Respect » Block Class doesn't work with Context
Status: Active » Fixed

Hi @david_garcia,

Thanks a lot for following-up on this issue and that's very good news to hear there is a patch for this issue.

This ticket has been getting longer and longer, drifting for a while when it was originally focused on the Context module.

I believe the problem related with Context was fixed long ago (otherwise there would have been many more complaints), therefore, I allowed myself to restore issue's initial title, change the status back to fixed and post a new issue, see: #2329563: Block Class doesn't work with Context Respect, where we could move all the discussions related to compatibility issues with the Context Respect module.

Feel free to re-open this issue, or post a new ticket, at any time if you have any further objections with this update/change or any of the related tickets (We would surely be happy to hear your feedback).

Please let me know if you would have any further comments, feedback, questions, issues, objections, suggestions or concerns on this ticket in general, I would be glad to provide more information or explain in more details.

Thanks again to everyone for your comments, questions, reviews, testing, reporting and feedback.
Cheers!

Status: Fixed » Closed (fixed)

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