This can be a refactor of entityreference_field_formatter_view and start using the theme system. This allow to handle or override much easier some features. Like the label link can be easily manipulate to add class and uri extra extensions.

This help for sitebuilders to use own hook_preprocess_entityreference_label(&$variables) and hook_preprocess_entityreference_entity_id(&$variables) as well you can do hook_theme_registry_alter() to override all.

Please take this in consideration.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

killua99’s picture

Status: Active » Needs review
FileSize
3.18 KB

As well this is the patch to apply this feature.

rozh’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

It is very usefull. Thanks for the patch!

tyler.frankenstein’s picture

+1 on the RTBC status!

DamienMcKenna’s picture

bisonbleu’s picture

I'm trying to add a button class to the A tag of the entityreference link as follows.

<div class="field field-name-field-update-event field-type-entityreference field-label-inline clearfix view-mode-full">
  <div class="field-label">Go back</div>
  <div class="field-items">
    <div class="field-item even">
      <a class="button" href="/event/test-test-fred">Referenced node</a>
    </div>
  </div>
</div>

Can this patch help me achieve that?
If so what would be the best way to do this ?

jdleonard’s picture

+1 RTBC. It's working on 7.x-1.2.

  • spotzero committed 414c079 on 7.x-1.x authored by killua99
    Issue #2088387 by killua99: Refactoring field formatter view into themes
    
spotzero’s picture

Status: Reviewed & tested by the community » Fixed

Took a little massaging to get it on to 7.x-1.x, but committed.

DamienMcKenna’s picture

Might this need a change notice?

spotzero’s picture

I can write one. I think this change only affects you if you're using template preprocess field to directly modify the "#markup" value directly if you're using the field formatter for label or entity id. Do you think this affects anyone else?

I had mixed feeling about this one because it could break stuff, but it does give the people whose stuff it breaks a much better way of doing what they were trying to do.

Status: Fixed » Closed (fixed)

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

blasthaus’s picture

+1 for a notice. this tripped us up for a minute since we were indeed theming reference fields with icons.

ladybug_3777’s picture

+1 for a notice. This completely caught me off guard and broke a large section of my site unexpectedly. My theme commonly uses the #markup field in order to compare and change the output of a taxonomy term.

The totally screwed up my working hook_preprocess_entity and hook_preprocess_field functions.

I simply had to change all my references from #markup to #label, but it caused a moment of panic for sure.

ladybug_3777’s picture

Hmmm.... actually just changing over to label isn't as straightforward as I thought... here's an example of a section of code I'm using to output the value of some custom fields in my taxonomy:

function _access_single_taxonomy_field_value(&$taxonomy_target, $taxonomy_field_name) {
   $fieldItem = field_get_items('taxonomy_term',$taxonomy_target, $taxonomy_field_name);
   $fieldItemOutput = field_view_value('taxonomy_term', $taxonomy_target, $taxonomy_field_name, $fieldItem[0]);
   return $fieldItemOutput['#markup'];

My return statement now is invalid, but ONLY when an entity reference field is passed to the function. Any other field type, #markup needs to be used. So now I'm going to have to try and check the type and then decide if I should be using #markup or #label.

It feels wrong that the field_view_value function should behave so differently based on field type now.....

spotzero’s picture

Without knowing what that code is actually trying to do, it looks like you're rendering a render array by popping out the markup into a string.

Instead of return $fieldItemOutput['#markup']; try return drupal_render($fieldItemOutput);

ladybug_3777’s picture

The function was simply returning the field's value as a simple string. In some cases that simple string is passed to other functions for comparison or it may be used to concatenate multiple field values into one variable. I don't want rendered HTML though... which I thought drupal_render() outputs. Am I incorrect in thinking that's what drupal_render does?

ladybug_3777’s picture

And forgive me if I've got the HTML value part swapped, I'm looking at some old code that we haven't touched in years, so digging back into the themeing layer of this particular section and finding this issue has me a bit out of sorts LOL!

spotzero’s picture

field_view_value() returns a render array generated by the field formatter, so that '#markup' value actually already contains rendered HTML. For this reason field_view_value() isn't really suitable for comparisions or operations on the field value.

However . . .
Since drupal_render happens to render '#markup' the same way your code does, essentially return $element['#markup'];.

and since the new ER template will render with a simple check_plain($label);

I'm pretty confident changing your code to return drupal_render($fieldItemOutput); will work just fine (and actually work exactly as it did before).

ladybug_3777’s picture

Great, thank you! After typing the first response I was thinking... "wait... actually I think #markup DOES have the HTML in it..." so I did have those swapped in my head at first. hahaha! Thanks for setting me straight. That sounds like a great solution then.

Another question for you.... if I'm going the other way around and was setting the markup value... and I WANTED to include HTML, the new ER change wouldn't allow for that?

so for example

$variables['items'][0]['#markup'] = "<strong>Bold value</strong>"; - would work and when it is output the string would be bold?

BUT

$variables['items'][0]['#label'] = "<strong>Bold value</strong>"; - would not show the string bold?

I don't THINK I'm loading HTML into my old #markup values like that, but your last comment made me think about it....

Going through old dusty code is rarely fun :-)

spotzero’s picture

You've got the render array, you can do anything you want with it before you render it:

$fieldItemOutput = field_view_value('taxonomy_term', $taxonomy_target, $taxonomy_field_name, $fieldItem[0]);
$fieldItemOutput['#prefix'] = '<b>';
$fieldItemOutput['#suffix'] = '</b>';
return drupal_render($fieldItemOutput);
dbdrupal’s picture

This broke just about every view on my site. I'm a site builder and not a developer, can anyone explain how I can fix my site. At this time I'm trying to roll back the changes.

spotzero’s picture

You can downgrade entity reference from https://www.drupal.org/project/entityreference/releases/7.x-1.2

I'm a little confused about how this could have broken all of the views on your site though, can you create a new issue and elaborate?

dbdrupal’s picture

I did the downgrade right after I posted last night and all is well except that I can no longer upgrade to the newer versions of this module. I believe there is already an issue out there for this because I clicked on a link to follow it over to this thread. If I have time this week, I will comment on that issue as well. Thanks.

MustangGB’s picture

This broke a lot of my views also, for reference they were setup something like this:

  /* Field: Content: ER */
  $handler->display->display_options['fields']['field_er']['id'] = 'field_er';
  $handler->display->display_options['fields']['field_er']['table'] = 'field_data_field_er';
  $handler->display->display_options['fields']['field_er']['field'] = 'field_er';
  /* Field: Content: ER PHP */
  $handler->display->display_options['fields']['php']['id'] = 'php';
  $handler->display->display_options['fields']['php']['table'] = 'views';
  $handler->display->display_options['fields']['php']['field'] = 'php';
  $handler->display->display_options['fields']['php']['php_output'] = '<?php
  if ($view->args[1] == \'_all\' && !empty($data->field_field_er)) {
    print $data->field_field_er[0][\'rendered\'][\'#markup\'];
  }

Switching from #markup to #label works, finding all the instances wasn't so easy.