Hi:

Many thanks for this very very useful module and the support you give us swentel!

- I have a 'blog' content type that includes a 'section' taxonomy reference field.
- In sections vocabulary I have created a view mode called 'Taxonomy term for node' that displays an image field
- In blog default display I've configured the default view to show the sections field with 'Taxonomy term for node' but it keeps using the default mode and ignoring the custom view mode.

Thanks.-

CommentFileSizeAuthor
#8 1143070-2.patch624 bytesneurojavi
#5 1143070.patch590 bytesswentel

Comments

neurojavi’s picture

Version: 7.x-1.0 » 7.x-1.x-dev

Confirmed in last dev version...

swentel’s picture

Status: Active » Postponed (maintainer needs more info)

Hrm works perfectly fine here, even in latest dev, so not sure what might be wrong here. Tempated to set it 'cannot reproduce' since it works perfect here, but I'll wait a bit more to see if others have the same problem.

neurojavi’s picture

Status: Postponed (maintainer needs more info) » Needs review

Hi:
I've been debugging for some time and I've found where the problem was...
My view mode was called 'taxonomy_term_for_node' (a very short name as the ones you like :-) so the str_replace in the formatter view function was deleting the string 'taxonomy_' from the beginning of the name...

/**
 * Implements hook_field_formatter_view().
 */
function ds_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  $element = array();
  $view_mode = str_replace('taxonomy_', '', $display['type']);
  foreach ($items as $delta => $item) {
    $build = taxonomy_term_view(taxonomy_term_load($item['tid']), $view_mode, $langcode);
    $element[$delta] = $build;
  }
  return $element;
}

I think it could be fairly common for people to use view names beginnig with taxonomy so I think it's worth changing str_replace with substr_replace('taxonomy_', '', $display['type'],0,9) or perhaps preg_replace...

What do you think?

In the meantime I've changed the view mode name and works fine.

Thanks for looking at this!

swentel’s picture

Ah, nice catch, never thought about that :)
substr_replace sounds good to me, it's probably a tiny bit faster than preg* functions .

swentel’s picture

StatusFileSize
new590 bytes

Can you test with this patch ?

neurojavi’s picture

Well, I've not tested the patch yet.
I've been thinking and looking at code and I think that this line is not needed at all.
Wouldn't be better not to add that prefix to view modes in ds_field_formatter_info()?
I mean changing
$formatters['taxonomy_' . $key] = array(
with this
$formatters[$key] = array(
here

/**
 * Implements hook_field_formatter_info().
 */
function ds_field_formatter_info() {

  $formatters = array();

  // Add view modes of taxonomy to term formatters.
  if (module_exists('taxonomy')) {
    $view_modes = ds_entity_view_modes('taxonomy_term');
    foreach ($view_modes as $key => $view_mode) {
      $formatters['taxonomy_' . $key] = array(
        'label' => t('View mode: ' . $view_mode['label']),
        'field types' => array('taxonomy_term_reference'),
      );
    }
  }

  return $formatters;
}

We're adding 'taxonomy_' prefix in formatter_info and deleting it in formatter_view. The only reason I can think for doing this is to avoid namespace conflicts but the only formatters existing for taxonomy terms are
taxonomy_term_reference_link and taxonomy_term_reference_plain, so the only possible conflict is that a view mode is named taxonomy_term_reference_link or taxonomy_term_reference_plain. This is very unlikely to happen and, in any case, adding the prefix we are moving the conflict to cases when the user has named term_reference_link or term_reference_plain his view modes (unlikely too but a little more possible). So, not solving anything...

What do you think about naming formatter the same as the view modes?

Another little question:
Looking at code I've noticed that, in the following function, the case for taxonomy_term_data is never executed because the entity name is taxonomy_term. We don't need this special case. I've tested a set message inside it and it seems that it's never reached. Am I right?

I think we can transform

/**
 * Get entity view modes.
 *
 * @param $entity_type
 *   The name of the entity type.
 */
function ds_entity_view_modes($entity_type = NULL) {
  if (!empty($entity_type)) {
    switch ($entity_type) {
      // For taxonomy terms the base table and the entity type are different
      case 'taxonomy_term_data':
        $entity_info = entity_get_info('taxonomy_term');
        break;
      default:
        $entity_info = entity_get_info($entity_type);
        break;
    }
    return $entity_info['view modes'];
  }
}

in this

/**
 * Get entity view modes.
 *
 * @param $entity_type
 *   The name of the entity type.
 */
function ds_entity_view_modes($entity_type = NULL) {
  if (!empty($entity_type)) {
    $entity_info = entity_get_info($entity_type);
    return $entity_info['view modes'];
  }
}

The changes are so little that I've not attached a patch. Please tell me if want me to attache one or two patches.

PS: The more I use and look to the code, the more I like this module, thanks a lot! :-)

swentel’s picture

IIRC, the only time that 'taxonomy_term_data' is passed is in views when listing terms. I'm using $this->views->base_table which in that case is 'taxonomy_term_data' (unless views has changed recently). In any case, that code could be simplified anyway, even if views still passes that string. We could modify it in the views implementation too of course.

function ds_entity_view_modes($entity_type = NULL) {
  if (!empty($entity_type)) {
    if ($entity_type == 'taxonomy_term_data') {
      $entity_type = 'taxonomy_term';
   }
   $entity_info = entity_get_info($entity_type);
   return $entity_info['view modes'];
  }
}

If we'd change the formatter, than we need an upgrade path which can be annoying since we'll have to find
a) the taxonomy fields and change their formatter
b) find any views which lists terms and uses view modes
c) maybe others than I forget now

so I'm tempted for the substr_replace option for now :)

neurojavi’s picture

StatusFileSize
new624 bytes

You're right. It's not woth the effort of such a complicated upgrade path. I was only enjoying and diving into code.

In any case you patch doen't work. It's my fault, I pointed you to substr_replace to avoid preg but that function only accepts 4 parameters and doesn't do what we expect.
I'm attaching a new patch with a conditional assignment to avoid preg. I've tested it with a taxonomy view mode named taxonomy_testmode and works fine.

I think this can be committed.

Thanks.-

swentel’s picture

Status: Needs review » Fixed

Joy is fun, nothing wrong with that :)
Patch committed and pushed, thanks!

Status: Fixed » Closed (fixed)

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