This is probably more of a generic theming question, and may be unrelated to Bean due to some of the abstractions in Drupal 7 that I'm just not up to speed on. But, I would like to be able to theme the content of specific bean types differently. Beans are essentially rendered through the Drupal block system, and in the block.tpl.php fils, as far I can see you only get access to the already rendered $content variable. I don't want to output the content exactly as it is in $content, but need to be able to do things with the individual fields, and display them in certain ways.

I know that Contemplate basically lets you do that for nodes, but these aren't nodes. And frankly, I'm not all too keen in the Contemplate approach.

Any thoughts/ponters?!

Comments

indytechcook’s picture

Status: Active » Fixed

Since we added a tpl and a them for the bean entity type, you can use hook_preprocess_bean() and/or using create a new beat.tpl in your theme just like you would a node.

Status: Fixed » Closed (fixed)

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

Coyote’s picture

Status: Closed (fixed) » Active

Okay: I have tried the following...

I've created a custom theme (based off adaptivetheme), and I've included a bean.tpl file in it.

That works fine.

But when I attempt to create theme suggestions for any bean__mybean_type.tpl.php files, they're never used, even though they're clearly in the template suggestions when I check $vars on hook_preprocess_entity - in fact they appear there regardless of whether I make theme suggestions in any of my code.

I've tried adding them with mytheme_preprocess_bean, as well as mytheme_preprocess_entity. Nothing appears to cause an override, no matter what I do.

mytheme_preprocess_bean doesn't actually do anything at all, and never fires no matter what. mytheme_preprocess_entity (naturally) fires as expected.

I've rebuilt caches repeatedly. Pretty much every other sort of theme override appears to work as expected - blocks, nodes, custom block types, etc. The only thing I can't seem to get to override is beans. They will _only_ use the bean.tpl.php template, though the override bean.tpl.php in my theme directory is used as expected.

But I need different themes for mah beans!

barraponto’s picture

Assigned: Unassigned » barraponto

Fixing this.

barraponto’s picture

saltednut’s picture

Can Bean plugins also be overridden in the theme using bean.tpl.php or a bean_plugin_title.tpl.php?

I may be doing something wrong- trying out a number of Bean plugins, I am unable to get bean.tpl.php to override the block output via my theme.

Beans created through the Admin UI are successfully overridden using bean.tpl.php inside the theme.

Regardless of specific theme rendering that goes into building $content['#markup'], all plugins eventually return $content; at the end of Bean::view() - this leads me to believe that these Beans should still be using bean.tpl.php for rendering their output. Thoughts?

David D’s picture

I can't get a custom tpl to work at all. Even when I copy bean.tpl.php to my theme folder and edit it without renaming the file, it has no effect on any beans. And a custom template file should follow this pattern: bean--beantypemachinename.tpl.php. Is that correct? I'm using 7.x-1.0-rc6.

caschbre’s picture

Check the links in #5. One of those mentions a core issue that is causing some theming issues with bean template files.

I was however able to copy bean.tpl.php to my theme and customize that one file. You'll have to put php logic in the template file since the proprocessor isn't working.

David D’s picture

I did check the links in #5, but it's all programmers talking to programmers, and I find it very hard to distill out anything that I can actually put to use in my case. I'm not a programmer, and it boggles my mind that this issue has apparently been around for nearly 2 years and is still unresolved. And not being a programmer, I don't know what to do with

You'll have to put php logic in the template file since the proprocessor isn't working.

I appreciate that you want to help, @caschbre. But this kind of thing drives me nuts, and makes me think it's a mistake to try to use Drupal when it's got so many random bugs like this.

caschbre’s picture

Sorry for not being more clear David. I don't always know who has a development background and who doesn't.

I understand your frustration but don't let it get you down. It's not uncommon for open source AND proprietary software to have bugs that persist. A lot of it depends on how many people are reporting it and wanting it fixed... along with someone finding the time to fix it or paying someone to fix it.

In this particular case, the bean module templating isn't working as expected. Right now only bean.tpl.php appears to be usable. The current assumption is that a core issue is affecting this. That core issue doesn't affect all modules, but there are some modules having similar issues.

We expect bean__bean-type.tpl.php (or something similar) to be able to handle theming various bean types. Until that is fixed we'll have to figure out a work-around.

From the sounds of it though you're having issues with bean.tpl.php which "should" be working. So let's tackle that issue first. If you make any changes to that file, clear your drupal caches, and then view your content it's not rendering with the changed template file?

indytechcook’s picture

You can use hook_preprocess_entity(). You can check $variables['entity_type'] == 'bean' for when the bean is being displayed. SEe template_preprocess_entity in the enitty api module for more information.

Also, the entity api module adds the following theme suggestions would *should* work for the tpl file, just not the preprocess.

  $variables['theme_hook_suggestions'][] = $entity_type;
  $variables['theme_hook_suggestions'][] = $entity_type . '__' . $bundle;
  $variables['theme_hook_suggestions'][] = $entity_type . '__' . $bundle . '__' . $variables['view_mode'];
  if ($id = entity_id($entity_type, $entity)) {
    $variables['theme_hook_suggestions'][] = $entity_type . '__' . $id;
  }

David, like caschbre said, make sure you clear the cache.

caschbre’s picture

@indytechcook... maybe I'm confused as to what the issue is. I thought the preprocess function wasn't firing to alter theme hook suggestions?

indytechcook’s picture

The bean preprocess function doesn't run but the entity one does. Or atleast it did at one time.

scottrouse’s picture

Status: Active » Closed (works as designed)

Ran into this article after some Googling, so I thought I'd offer my thoughts and close out this Issue.

Without any other preprocess theme hook suggestions, I was able to copy bean.tpl.php into my theme's directory and duplicate it as bean--[block-type-machine-name].tpl.php. In other words, if the block type was "custom-block", the tpl file would be named bean--custom-block.tpl.php.

So, this works just like node.tpl.php files.

barraponto’s picture

Status: Closed (works as designed) » Needs work

however, neither template_preprocess_bean nor template_preprocess_bean__custom_block run (yet). So we're still looking for a solution :/ Keep in mind, though, that we're working on fixing it either on Entity module (bad) or Drupal Core itself (good).

rooby’s picture

Status: Needs work » Active

Isn't this a duplicate of #1361756: More theme candidates

ahimsauzi’s picture

There seems to be a weight or precedence conflict with the block module. In my case, there was a block.tpl.php in the theme that I had to override some elements on it (primarily the $title output) in order for the bean.tpl.php changes to show up. That said, #15 works and is being called.

dgtlmoon’s picture

Mental note

use "bean--machine-name--default.tpl.php" as the template file, seems to work in latest bean module (1.5 atleast)

tarekdj’s picture

+1 dgtlmoon. It works!

saltednut’s picture

Issue summary: View changes
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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

paskainos’s picture

To help clarify; I noticed Devel Themer is now presenting the following tpl candidate files:

  • bean--[bean-block-label].tpl.php
  • bean--[machine-name]--default.tpl.php
  • bean--[machine-name].tpl.php

This also presents bean.tpl.php as the base candidate template file.

Guito339’s picture

Block Entities Ain't Nodes, but they are blocks :)

As per #15 i could not get the [theme]_preprocess_bean to run still. As a work around i used [theme]_preprocess_block as follows:

function my_theme_preprocess_block(&$variables) {
  $block = $variables['block'];
  if ($block->module == 'bean' && $block->delta == '[the delta for the created bean]') {
    $bid = db_select('bean', 'b')
      ->fields('b', array('bid'))
      ->condition('b.delta', '[the delta for the created bean]')
      ->execute()->fetchField();
    $bean = bean_load($bid);
    if ($bean->type == '[The type of bean you want to preprocess]') {
      $variables['variable_name'] = $bean->[some property or field of the bean];
    }
  }
}

I created a block type named Download Magazine (download_magazine) where the delta was 'current-issue' created from the label of the bean, Current Issue. The bean has 5 fields Magazine Cover (image), Download Link (link), Body Text (longtext), Use Captcha (boolean), and Captcha Url (text)

I was then able to add keys to the variables array to use in a block template file as follows:

function my_theme_preprocess_block(&$vars) {
  $block = $vars['block'];
  if ($block->module == 'bean' && $block->delta == 'current-issue') {
    $bid = db_select('bean', 'b')
      ->fields('b', array('bid'))
      ->condition('b.delta', 'current-issue')
      ->execute()->fetchField();
    $bean = bean_load($bid);
    if ($bean->type == 'download_magazine') {
      $vars['bean_title'] = $bean->title;
      $vars['bean_body'] = $bean->field_description_body_text['und'][0]['value'];
      $vars['bean_magazine_cover_src'] = file_create_url($bean->field_magazine_cover['und'][0]['uri']);
      $vars['bean_download_link_text'] = $bean->field_download_link['und'][0]['title'];
      if ($bean->field_use_captcha['und'][0]['value']) {
        $vars['bean_download_link'] = url($bean->field_captcha_url['und'][0]['value'], array('absolute' => TRUE));
      }
      else {
        $vars['bean_download_link'] = url($bean->field_download_link['und'][0]['url'],
          array(
            'absolute' => $bean->field_download_link['und'][0]['absolute'],
            'target' => $bean->field_download_link['und'][0]['attributes']['target'],
          ));
      }
    }
  }
}

and my template file, block--bean--current-issue.tpl.php (block--[module]--[delta].tpl.php), copied from bean.tpl.php and renamed, uses these variables instead of calling functions so we maintain that themes are for display only, not logic or function calls.

<div class="<?php print $classes; ?> clearfix"<?php print $attributes; ?>>
  <div class="content"<?php print $content_attributes; ?>>
    <div class="sidebar-block-title yellow">
      <?php print $bean_title; ?>
    </div>
    <div class="download-text">
      <?php print $bean_body; ?>
    </div>
    <div class="magazine-cover">
      <a href="<?php print $bean_download_link; ?>">
        <img src="<?php print $bean_magazine_cover_src; ?>" /></a>
    </div>
    <div class="download-link">
      <a href="<?php print $bean_download_link; ?>">
        <?php print $bean_download_link_text; ?></a>
    </div>
  </div>
</div>

The code doesn't directly download the magazine in this case as the client wanted the user to be directed to a captcha page before the download. I added a field set to the block type to choose if captcha should be used and what the captcha url is. the preprocess helps check for the correct url to use in the links in the template file. A preprocess function is better for this logic than in the template file.

I hope this helps those trying to use preprocess on bean entities.

rooby’s picture

@Guito339 you might be interested in #2423183: Add block template suggestions per bean type