When I add the php code to block.tpl.php in Omega 3 subtheme I get the following error.

Notice: Undefined variable: block_classes in include() (line 2 of C:\drupal\website\sites\all\themes\myomegasubtheme\templates\block.tpl.php).

Here is my block.tpl.php

<?php $tag = $block->subject ? 'section' : 'div'; ?>
<<?php print $tag; ?><?php print $attributes; ?> <?php print $block_classes; ?>>
  <div class="block-inner clearfix">
    <?php print render($title_prefix); ?>
    <?php if ($block->subject): ?>
      <h2<?php print $title_attributes; ?>><?php print $block->subject; ?></h2>
    <?php endif; ?>
    <?php print render($title_suffix); ?>
    
    <div<?php print $content_attributes; ?>>
      <?php print $content ?>
    </div>
  </div>
</<?php print $tag; ?>>

Comments

konordo’s picture

konordo commented

Just replace in the block.tpl.php this:
<?php print $block_classes; ?>
with this:
<?php if (isset($block_classes) && !empty($block_classes)) { print $block_classes; } ?>

mustardman’s picture

mustardman commented

That seems to work. Thank you.

jacobstow’s picture

jacobstow commented

I'm also getting this problem, though using a different theme. If I replace as described above it removes the error message, but there are still no classes coming through in the output. Any ideas what I can try?

netes’s picture

netes commented

Are you sure you enabled the module?

jacobstow’s picture

jacobstow commented

Yes, it's definitely enabled. In the end it was block_classes that was the issue, it worked when changed to:

<div class="<?php print $classes; ?>">

as per the system block.tpl.php, I'm guessing my theme doesn't support block_classes or some such..

dydave’s picture

dydave commented
Category: bug » support
Status: Active » Fixed

Hi guys,

Thanks very much for reporting this issue.

I'm not exactly sure I completely understand the problem here:

Could you please explain where the code: <?php print $block_classes; ?> (in template file, see in issue summary or at #1) would come from?
Could you please let us know if this code was found on module's project page?
If you copied a snippet from the project page maybe we would need to make it clearer (even more obvious) that specific snippets require corresponding versions.
But in my opinion the project page is already very clearly divided with the different snippets for different versions:

  • 7.x-1, 6.x-1.3 or lower would support <?php print block_class($block); ?>
  • 6.x-dev, 6.x-1.4 or greater would support <?php print $block_classes; ?>

Feel free to let us know if you would like to suggest a documentation improvement or an update of the module's page description, we would surely look into it with a great interest.

From a coding standpoint, as far as the 7.x-1.x version would be concerned, it wouldn't have anything to do with the $block_classes template variable (which by the way wouldn't exist by default, unless it is implemented by a custom module or theme and I would be glad to hear some feedback on that).
The 7.x-1.x and 7.x-2.x versions modify the classes_array property of the theme variables for any blocks, see block_class.module, line 46:
<?php $vars['classes_array'] = array_merge($vars['classes_array'], explode(' ', $classes)); ?>

Therefore, by default (if no external/specific logic alters the Core behavior), it would have to be accessed through the Core Block theme variable $classes (as it was correctly mentioned at #5, see in block.tpl.php, line 13).

Personally, I would think the solution proposed in #1 would only work with 6.x-dev, 6.x-1.4 or greater versions, I'm rather surprised it did for #2 and not at all no classes would display as mentioned in #3, which I would think would be the result to expect since the $vars['block_classes'] wouldn't be defined in template variables.
In any case, we would need more precise information on the exact versions of the module for which this issue would have been encountered.

It is also possible that certain themes or modules alter the default behavior and add their own template variables, properties or logic.
I would assume the integration/support with Block Class would require some additional work in theming, but a fairly straight forward solution would be to override theme_preprocess_block in theme's template.php file and set the theme variable $vars['block_classes'] with whatever value with any logic, accessing the block classes through:

  • 7.x-1.x: <?php block_class($vars['block']); ?> in the template.php file, and <?php print block_class($block); ?> in the block template file (.tpl.php).
    As mentioned on the project page description, in the first section called: How to add the PHP snippet (7.x-1.x, 6.x-1.3 or lower).
     
  • 7.x-2.x: <?php $vars['block']->css_class; ?> in the template.php file, and <?php print $block->css_class; ?> in the block template file (.tpl.php).

    • Note that in the 7.x-2.x version, since the css_class is a property of the block object, it could also be accessed through <?php $block->css_class; ?> at different levels of the loading/rendering process.
    An issue has been tracked at #1936504: [Document]Update project page for 7.x-2.x to add more information to the project page about this branch and its related snippets.

I hope this answer will help clarifying a little bit how to access at the theme level (template tpl files or template.php) custom block classes added through Block Class.

I allowed myself to move this bug report to support request (since it seems everything is working as expected) and 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, questions or comments with any points discussed in this comment.

I would certainly greatly appreciate to have your feedbacks, comments, questions, issues, objections, reviews, testing, reports, suggestions or concerns on this ticket, I would be glad to provide more information or explain in more details.

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

Status: Fixed » Closed (fixed)

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